Рендеринг в пользовательский DrawingContext

Question

Я хотел бы захватить обычный рендеринг WPF, чтобы разделить элементы управления на примитивы, сделать управление макетами, применить привязки и т. Д. Для меня.

Насколько я понимаю, весь рендеринг в WPF сводится к рендерингу примитивов (текст, изображение, линия, кривая) в местах, рассчитанных менеджером компоновки со значениями, определенными системой свойств зависимостей. Если бы я мог предоставить свою логику примитивного рендеринга, я бы смог отобразить, например. для пользовательского типа документа, передача примитивы для реального рендеринга по сети и т.д.

Мой план заключается в следующем:

1. Реализация пользовательских DrawingContext. DrawingContext является абстрактным классом, который определяет набор методов, таких как DrawEllipse, DrawText, DrawImage и т. Д. - Мне нужно предоставить собственную реализацию для этой функции.
2. Создайте WPF UserControl и заставьте его визуализировать в заданный DrawingContext.

Однако я столкнулся со следующими проблемами:

1. DrawingContext содержит абстрактные внутренние методы void PushGuidelineY1(double coordinate) и void PushGuidelineY2(double leadingCoordinate, double offsetToDrivenCoordinate), которые я не могу переопределить легко. (Возможно, есть какой-то трюк, чтобы преодолеть это?)
2. Нет никакого способа визуализации всего визуальный на DrawingContext? Зачем?

я могу сделать что-то вроде

void RenderRecursively(UIElement e, DrawingContext ctx) 
{ 
    e.OnRender(ctx); 
    for (int i = 0; i < VisualTreeHelper.GetChildrenCount(e); i++) 
     RenderRecursively((UIElement)VisualTreeHelper.GetChild(e, i), ctx); 
} 

- но мне интересно, если есть прямой путь для визуализации UIElement. (Конечно, эта проблема является второстепенной, но отсутствие инфраструктуры для нее заставляет меня задаться вопросом, правильно ли это.)

Итак, есть DrawingContext, не предназначенный для наследования? Является ли вся идея поставки пользовательского DrawingContext шагом в правильном направлении или мне нужно переосмыслить стратегию? Является ли рисование на пользовательском контексте, поддерживаемом в WPF, или мне нужно искать другую точку перехвата?

Answer 1

Возможно, вам придется обратиться к этой проблеме с противоположного направления. Вместо того чтобы стремиться предоставить свой собственный DrawingContext, вы можете вместо этого попросить WPF предоставить вам Drawing. Таким образом, это скорее «тянущий» подход, чем подход «толчок», на который вы нацеливаетесь, но он должен позволять добраться до того же места: если у вас есть Drawing, что является полным представлением о появлении части визуального дерева, это структура данных, в которую вы можете ходить, и обнаружите все, что вы обнаружили бы из вызовов пользовательского DrawingContext.

Я считаю, что это тот же базовый подход, что и документ XPS, который упоминает Себастьян, использует внутренне. Но использование его непосредственно непосредственно - это более прямой подход, чем использование его через API XPS.

В основе всего, что-то довольно простое: VisualTreeHelper.GetDrawing. Это возвращает DrawingGroup. (Drawing - абстрактный базовый класс.) Эта страница документации показывает вам, как пройти через дерево, которое вы вернетесь. К сожалению, это не делает всю работу: она просто предоставляет визуальные эффекты для того, какой узел вы вызываете, и если у этого узла есть дети, они не будут включены.

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

Answer 2

Я попытался сделать подобное, чтобы создать FlowDocumentViewer для winRT. Но поскольку WinRT гораздо менее зрелый по сравнению с WPF, он также слишком много передает на собственный слой (через поток рендеринга), которого я не мог получить нигде. Но это то, чему я научился, и надеюсь, что я объясню это хорошо.

WPF использует аппаратное ускоренное отображение графики. Таким образом, в упрощенном виде WPF LayoutEngine создает логическое визуальное дерево, которое затем преобразуется в команды рендеринга, которые затем отправляются на аппаратное обеспечение Graphics для выполнения или рендеринга.

DrawingContext - это нетривиальный класс, он взаимодействует с базовой графической системой для рендеринга, управляет масштабированием, кэшированием и т. Д. Время выполнения WPF поставляется с реализацией по умолчанию, которая выполняет визуализацию всех визуальных эффектов. IMO, причина, по которой это сделано в абстрактном классе, поэтому Microsoft может предоставить различные реализации для Silverlight и т. Д. Но это должно быть переопределено нами.

Если вы должны заменить рендеринг WPF, то лучше всего создать UserControl, переопределить Arrange и Measure calls и визуализировать каждый элемент DrawingVisual с помощью DrawingVisual.RenderOpen() и упорядочить их и т. Д. Из вашего кода. Управление уведомлениями о передаче данных - это еще одна вещь, которую вам придется делать самостоятельно.

Кажется, очень интересный проект. Удачи!

Answer 3

Я думаю, что ваш подход не будет работать, потому что (как упоминалось в других источниках) вы не можете предоставить свою собственную реализацию DrawingContext.

Вместо этого я предлагаю следующее: чтобы «сгладить» рендеринг WPF, WPF экспортирует ваши визуальные изображения в документ XPS. Во время этого процесса весь рендеринг в основном перечисляется как простые примитивы рендеринга, и все, что вы оставили, это Canvas s, основные фигуры, глифы и другие примитивы рисования.

Затем повторите визуализацию на страницах документа. Насколько я знаю, полученный визуал будет состоять только из примитивов, поэтому нет необходимости звонить OnRender. Вместо этого вы можете внешне визуализировать визуальные экземпляры (используя instanceof -каскады и чтение/интерпретацию свойств). Это все еще довольно много работы, потому что вам нужно интерпретировать свойства так же, как это делает WPF, но, насколько я мог видеть, это должно работать, по крайней мере, для многих основных случаев использования.

Answer 4

Вместо того, чтобы пытаться написать свой собственный DrawingContext, может быть, вы могли бы создать класс, производный от FrameworkElement или UIElement или даже Visual, который выполняет свою деятельность в методе OnRender. Вы все равно должны использовать данные реализации Draw[Something], но вы будете контролировать аргументы и порядок операций.Вы все еще можете анализировать примитивы и инструкции из вторичного источника, а ваш UIElement/FrameworkElement может составлять инструкции во время выполнения.