Каковы недостатки кэширования растровых изображений в Silverlight 4? - PullRequest
2 голосов
/ 19 ноября 2010

Мы смогли решить проблему высокой загрузки ЦП, используя растровый кэш Silverlight, как описано здесь:

Мы добавили параметр EnableGPUAcceleration в тег . Чтобы снизить нагрузку на процессор до разумного уровня, нам пришлось добавить CacheMode = "BitmapCache" в корневую визуальную сетку для всего приложения. Поэтому мне интересно, есть ли минус в том, чтобы так сильно полагаться на растровый кеш. Если бы это всегда было выгодно, я предполагаю, что это будет включено по умолчанию.

Я нашел этот похожий вопрос с хорошим ответом от AnthonyWJones:

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

Если видеокарта не имеет достаточного количества видеопамяти для кэширования всего, я предполагаю, что Silverlight будет изящно деградировать и просто будет использовать больше циклов ЦП для повторного рендеринга интерфейса.


Спасибо за вашу помощь,
Ричард

Ответы [ 2 ]

5 голосов
/ 08 декабря 2010

После долгих экспериментов с кэшированием растровых изображений мы отключили его в нашем приложении.Это хорошо работает, когда вы хотите использовать графический процессор для выполнения преобразований на части вашего пользовательского интерфейса, которая не изменяется - например, если у вас есть изображение, которое вы хотите анимировать, сжать, повернуть и т. Д. Но растровое изображениеускорение кэширования / графического процессора (в его текущей реализации) значительно замедляет процесс, если вы продолжаете обновлять визуальное дерево внутри той части вашего пользовательского интерфейса, которую вы хотите кэшировать / манипулировать.Если вы просто перемещаетесь по статическому растровому изображению, имеет смысл кэшировать его и использовать графический процессор для его ускорения.Но довольно часто вы можете настраивать фрагменты где-то вниз по визуальному дереву из фрагмента вашего пользовательского интерфейса, который вы отметили для кэширования, и если это происходит, вам нужно обновлять кэш GPU каждый кадр, и это медленно, медленно, медленно.

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

1 голос
/ 08 декабря 2010

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

Скажем, например, у вас был «верхний» холст размером 500x500, и он содержал 25 «вспомогательных» холстовкаждый 100х100.Допустим, мы обновляли содержимое / цвета и т. Д. В каждом из под холстов.Допустим, было событие, которое переместило бы верхний холст на экран.Если бы все вспомогательные полотна изменялись с одинаковым интервалом, имело бы смысл кэшировать только растровое изображение верхнего холста.Однако, если вспомогательные полотна не изменились с одинаковым интервалом, а иногда и вовсе не изменились, может оказаться более выгодным установить вместо этого кэширование растрового изображения на каждом подчиненном полотне.Если сделать еще один шаг вперед, если растровое изображение кэширует как верхний, так и каждый вспомогательный холст, могут быть потрачены впустую циклы кеширования чего-либо без пользы.

Или я иду по совершенно иному пути, чем тот, о котором вы спрашиваете?

...