Я создаю пользовательскую структуру пользовательского интерфейса в WPF, где я в основном отказываюсь от встроенной системы компоновки и элементов управления, насколько это возможно. До сих пор я отделялся от UIElement напрямую, но, поскольку я уже выполняю измерения, аранжировку и рендеринг самостоятельно, я думаю, что мог бы отрезать больше от наследия WPF, став еще «ближе к металлу» (особенно когда это доходит до верстки/рендеринга). Насколько близко можно подойти, оставаясь в управляемом коде и не боясь самому делать грязную работу?
Сейчас я играю с концепцией прототипа на стороне, где у меня есть только один элемент, наследуемый от UIElement: объект Root, похожий на урезанный Canvas, который «размещает» остальную часть моего механизма компоновки и направляет в него соответствующие IInputElement преимущества. С этого момента все элементы будут полностью пользовательскими объектами, не наследуемыми ни от чего в WPF, а визуализируются непосредственно в DrawingContext корня (в его методе OnRender).
Теперь меня интересует относительная производительность наличия корневого элемента WriteableBitmap и его ручного рисования, например, с помощью WriteableBitmapEx для удобства. Отсутствие сглаживания не является проблемой, равно как и настраиваемая система проверки попаданий.
Мои мысли в первую очередь заключаются в том, что WriteableBitmap (Ex) не имеет привилегии какого-либо ускорения ускорения графического процессора и, следовательно, будет [намного] медленнее, когда необходимо перерисовать / преобразовать большие области.
Однако у меня есть другие потребности в «движке рендеринга на основе пикселей в движке», поэтому меня все еще интересует некоторая точка зрения на это.
Любые идеи?
Редактировать: А как насчет SharpDX в этом контексте? Может быть, когда я начну, я мог бы также выбрать решение WinForms с оболочкой DirectX, такой как SharpDX (..или.. Я думаю, что я действительно должен сделать, это подписаться на всю энчиладу C++ , но, к сожалению, у меня нет времени, чтобы начать изучать это в гуще событий)..
