FillGeometry намного медленнее на UWP по сравнению с рабочим столом?

UWP-версия нашего приложения работает с гораздо меньшей частотой кадров (6 кадров в секунду против 24 кадров в секунду) по сравнению с эквивалентом рабочего стола. Обратите внимание, что обе версии были протестированы на оборудовании того же.FillGeometry намного медленнее на UWP по сравнению с рабочим столом?

Обе версии построены с использованием SharpDX, единственное отличие в том, как настроены RenderTargets. Приложение Windows использует HwndRenderTarget, а приложение UWP использует кисть SurfaceImageSource, которая рисует в Rectangle.

Мы сузили главного виновника (по крайней мере, на стороне процессора) до FillGeometry, который потребляет много времени на UWP.

Есть ли причина, по которой FillGeometry займет намного больше времени в приведенной выше конфигурации UWP по сравнению с рабочим столом?

Примечание: код рендеринга идентичен для обоих, поэтому избегайте предложений, которые одинаково влияют на обе реализации, например, используя GeometryRealization вместо Geometry. Мы ищем причину разницы между производительностью рендеринга на UWP и рабочим столом.

Если есть факторы, отличные от геометрии, которые могут повлиять на производительность, было бы полезно знать их также, так как наши инструменты профилирования могут быть не совсем точными.

источник

2015-11-18 bright

Я уверен, что настольный компьютер имеет гораздо лучшую графическую карту, чем телефон. Лучшая графическая карта означает лучший gpu –

Возникает ли эта проблема с производительностью и без .NET Native (сборка DEBUG/RELEASE в VS)? У них есть разные блоки взаимодействия и компилятора, что может помочь в отслеживании этого. –

Кен - обе версии были запущены на одной машине. Мэтт - оба являются сборками DEBUG. .Net native имеет проблемы (он никогда не завершается), поэтому нельзя использовать это на данный момент. – bright

Одним из факторов, по-видимому, является то, что внутренняя обрезка Direct2D работает по-разному в этих случаях.

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

Когда было добавлено явное обрезание, частота кадров для версии UWP увеличилась примерно до 16 кадров в секунду (еще меньше, чем у настольного приложения), в то время как частота кадров в настольной версии не сильно повлияла.

Итак, на данный момент это гипотеза о том, что в этих двух случаях работают различные процедуры отсечения.

Это не полностью решено, так как мы все еще имеем существенную разницу в частоте кадров. Но это начало.

источник

2015-11-19 08:57:29 bright

FillGeometry намного медленнее на UWP по сравнению с рабочим столом?

ответ

Смежные вопросы