[cairo] glitz internal and cairo rendering model

[Jon Smirl]

--- Stéphane_Conversy <conversy at cena.fr> wrote:
> I'm considering interaction in a zoomable user interface (ZUI). As you 
> zoom in, there is no need to tesselate
> a shape each frame. Just tesselate it once for all at a sufficient LOD, 
> then reuse it for each frame.

Use the proposed display list surface for glitz and set it for high resolution
so there will be lots of tessellation detail. Then copy that surface to the real
one as the zoom factor changes. It won't be hard to build the display list
surface, glitz is just going to use GL to do all of the work.

Don't forget about fonts. If we had hardware scalable fonts all of the windows
could be drawn to display lists instead of pbuffers. Then keith's xserver could
play these at whatever resolution was needed.

This brings up a thought, what if we made a cairo level display list - ie a
display list of Cairo commands? Then if a window was completely painted using
Cairo the entire window would be stored as a Cairo display list. Glyphs would
not have been converted to bitmaps yet. xserver would then play these display
lists through whatever transform and generate the correct glyph bitmaps and
tessellation level. Cairo display lists should be more memory efficient than
pbuffers for the window. They would also provide better glyph caching since
xserver would be managing the glyph-bitmap conversion. Or is this a reinvention
of display postscript?

In the remote case this model would be better since all of the drawing commands
are cached in the server. In the local case it might be faster to just send the
app a redraw message with the new resolution/transform. Experience has shown
that apps are much better at understanding their own retained mode model than
the windowing system is.

=====
Jon Smirl
jonsmirl at yahoo.com


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/