Станислав Макаров

1) вы так легко считаете память, выделяемую под ваши кубы). Я думаю это весьма далеко от истины, т.к. лично я даже предположить не смогу, что конкретно происходит при создании дотнетовского объекта и сколько конкретно он потребует памяти;

2) вы используете инструмент не по назначению. WPF - это для относительно малого числа граф. объектов (десятки, сотни) с высоким уровнем интерактивности для каждого из них. Иными словами - для интерфейсов. В интерфейсах есть небольшое количество высокоинтерактивных объектов - кнопок, скроллов, комбобоксов, и именно для таких сценариев WPF и оптимизирован. Вам с 10К кубами уже давно пора брать Direct3D и не мучаться. Это я вам не с потолка говорю, мы тоже когда-то пытались использовать WPF-шную двухмерную графику для двухмерной отрисовки, но быстро поняли, что его инфраструктура слишком тяжелая для нашей задачи. Вы замучаетесь в попытках это все оптимизировать.

1) переделайте/сконвертируйте изображение так, чтобы это был Drawing:

<GeometryDrawing Brush="#FF8B0000">
      <GeometryDrawing.Geometry>
        <PathGeometry ....... />
      </GeometryDrawing.Geometry>
    </GeometryDrawing>

Если PathGeometry несколько, используйте DrawingGroup.
2) поместите полученный XAML в ресурсы;
3) попробуйте мой велосипед для того, чтобы поместить изображение в кнопку:

<Image Source="{Binding Source=путь_к/картинке.xaml, Converter={StaticResource ResourceUriToDrawingImageConverter}}" />

Код конвертера:

public class ResourceUriToDrawingImageConverter : IValueConverter
	{
		public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
		{
			Uri uri =
				value is Uri ?
					value as Uri :
				value is string ?
					new Uri(value as string, UriKind.RelativeOrAbsolute) :
					null;

			if (uri == null)
			{
				throw new Exception("Invalid URI value");
			}

			StreamResourceInfo sri = Application.GetResourceStream(uri);
			if (sri == null)
			{
				throw new Exception("Resource not found");
			}

			using (Stream stream = sri.Stream)
			{
				var drawing = XamlReader.Load(stream) as Drawing;
				if (drawing == null)
				{
					throw new Exception("Resource cannot be converted to drawing");
				}

				return new DrawingImage(drawing);
			}
		}

		public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
		{
			throw new NotImplementedException();
		}
	}

P.S. Следите за репой https://github.com/Nipheris/SharpVectors.MSBuild - там скоро появятся MSBuild-таски для конвертирования SVG прямо во время сборки проекта.

Т.е. нужна некая философия

А какие книги вы уже пробовали читать, раз такое спрашиваете?

Ведь философия очень простая. Идея обработки ошибок с помощью механизма исключений сводится к тому, чтобы не захламлять основной алгоритм логикой обработки ошибок и иметь возможность локализовать эту обработку в одном месте, причем не где-нибудь, а именно там, где известно, как ошибку обработать.
Использование механизма исключений вместе с ООП-шной иерархической классификацией дает возможность обобщать исключения различной природы, если код их обработки также общий и не вдается в детали ошибки.

Все это дает вам набор простых правил:
1) выбрасывать исключение нужно тогда, когда вы не собираетесь обрабатывать возникшую ситуацию в рамках текущего алгоритма. Иными словами, для работающей в данный момент функции эта ситуация - "исключительная". Пример: вы пишете функцию для чтения GIF-файла в Bitmap, и по ходу чтения проверяете соответствие получаемых данных формату GIF-файлов (например, убеждаетесь в наличии GIF89a в начале файла). Если вдруг вы видите, что формат файла нарушен, то вам ничего не остается кроме как выбросить исключение, т.к. вы не можете продолжить выполнение основного алгоритма - считывание файла. Внутри функции считывания вы не знаете заранее, как вызывающий код захочет обработать эту проблему, вам и не нужно это знать;
2) перехватывать исключение конкретного типа нужно тогда, когда в задачу текущего кода входит и обработка ошибок тоже. Иными словами тогда, когда исключение в вызванном коде - лишь один из вариантов нормальной работы вызывающего кода. Вернемся к примеру с GIFками: если для библиотечной функции чтения файла нарушение формата - это критическая проблема, то для вызывающего эту функцию GUI-приложения это нормальная ситуация - ее можно и нужно обработать, выдав пользователю соответствующее сообщение, или просто пропустить файл, если обрабатывается сразу несколько картинок. Или например, если вы пишете веб-сервис, вы врядли хотите, чтобы весь сервис прекратил работу из-за ошибки при обработке какого-то одного запроса. Поэтому в веб-сервере, раздающем файлы вы, к примеру, можете перехватывать все FileNotFound исключения, и выдывать ошибку 404, а на все остальные исключения внутри обработчика запроса - ошибку 500 и в обоих случаях писать в error.log.

Следует понимать, что исключения - лишь один из подходов к обработке ошибок, естественно сочетающийся с возможностями некоторых языков. В Си, например, обходятся без них, и все живы и здоровы.

Отличный пример разных подходов - методы Parse/TryParse у числовых типов в дотнете. Первый возвращает значение и выбрасывает исключение, второй записывает значение через выходной параметр, возвращает bool и НЕ выбрасывает исключение. "Try" в названии второго метода подчеркивает, что для этого метода неудача при попытке распарсить число из строки - НОРМАЛЬНАЯ ситуация, и метод в этом случае вернет false. Для метода Parse напротив, такая ситуация будет исключительной, т.к. ему просто-напросто нечего будет возвращать, и дальнейшая нормальная работа кода, в том числе вызывающего, невозможна.
Поэтому метода TryParse чаще используют тогда, когда вероятность ошибки высока и ее обработка - одна из ветвей алгоритма. Например при считывании пользовательского ввода мы сразу можем попросить пользователя исправить введенное значение.
С другой стороны, Parse применяется если ошибка маловероятна, мы не готовы ее обработать и лучше прервать всю операцию целиком. Например если мы получили от сервера невалидный ответ, мы не попросим его исправить этот ответ. Дальнейшее общение с сервером лучше прервать, т.к. имеет место нарушение протокола и можно наломать дров.

Судя по скрину, у вас для UTF-8 потерялся BOM.
Скорее всего это произошло потому, что вы считали файл неверной кодировкой (в файле у вас UTF-8 вроде как). Используйте кодировку явно, например UTF8Encoding вместо дефолтовой.

Начните с https://msdn.microsoft.com/en-us/magazine/dd419663.aspx .

После прочтения статьи должны придти к выводу, что главное а) построить правильную ViewModel; б) записать правильные привязки. Не факт, что получится обойтись без генерации контролов из кода. Но даже в этом случае содержимое статьи должно быть применимо.

с подсветкой синтаксиса

хм, неплохо если вы его уже реально напишите.

Собственно, что нужно читать, писать, смотреть, чтобы развиваться?

Прикладное направление выберите для начала. Стандартный выбор на сегодня: веб-бэкенд/десктоп/игры/мобайл. Соответственно: ASP.NET 5ASP.NET Core 1.0/WPF/Unity/(UWP/Xamarin)