[Moonlight-list] initial bitmap caching

Larry Ewing lewing at gmail.com
Wed Nov 18 11:37:19 EST 2009

On Tue, Nov 17, 2009 at 7:35 PM, David Reveman <davidr at novell.com> wrote:
> not sure I understand the xaml parsing code completely yet. the attached
> patch to xaml.cpp (moon-cache-mode-from-str.diff) is required to parse
> the "CacheMode" property as a none XAML property element. works but i
> don't know if this is the appropriate way to solve this..
> moon-bitmap-cache.diff is some initial code that implements bitmap
> caching. likely not exactly what we want to use but it works ok and
> gives about 100% performance improvement to a simple test like
> bubblemark.com. it's completely broken in the sense that it doesn't
> invalidate the bitmap cache as the sub-hierarchy of a uielement changes.
> there seems to be a lot of unnecessary invalidation taking place right
> now which makes the bitmap cache useless and that needs to be resolved
> first..

We're definitely invalidating too much right now much it of because of
how the rendering system had to change between moonlight 1 and 2.  I
haven't yet had time to go back and clean things up but there should
be some low hanging fruit.

> another problem in the patch is the ugly handling of the LayoutClip.
> this is because the layout clip is not passed top-down through the
> hierarchy during rendering but instead fetched bottom-up, which prevents
> the bitmap caching code from properly making adjustments to the layout.

Yeah the bottom up fetch is an artifact of trying to figure out how it
is supposed to work in Silverlight.  You should be able to carry the
layout clip down as part of the render pass but be aware that it has a
separate coordinate space from the global render transform so you'll
need to keep track of it separately.  It accumulates the layout
transform only as you go down the tree and is then applied in the
child's coordinate space.  The bottom up fetch is near the top of my
list of things to fix so if you have questions or would rather work on
something else let me know.

> i'm currently working on fixing the invalidation and layout clipping
> problems as they are crucial to implementing other features like
> perspective transformations and pixel shaders. ideas and recommendations
> are of course much appreciated.

My only advice here is that you don't have to wait to get the
invalidation logic sorted out before putting the broader features even
if it is required for them to be useful in practice.  Debugging
invalidations is something many eyes can help on and is often easier
to follow and bisect regressions if done incrementally in the tree.
Great to see some progress on this stuff.


More information about the Moonlight-list mailing list