Re: About gtk/cairo integration.

[Jost Boekemeier <jost2345 yahoo de>]

[retained rendering]
> we can layer them on top and still expose 
> cairo directly as an immediate mode API

Okay.  


Rest of my mail will get a bit off-topic.

> the way I'd envision it working is that you 
> just use cairo's current clipping facilities when 
> doing cairo_show_surface() from a retained 
> mode surface to an immediate mode surface

We want to exclude certain parts of the vector picture
and send only the visible parts to the server-side
because server-side resources are limited.

Your proposal above has the problem that you cannot
hardware accelerate the drawing anymore:

It is not possible to decide what to send to the
server-side and what not until you apply the
transformation matrices.  If apply them on the 
client-side, this would be equivalent to rendering the
picture into a plain image on the client. 

I think there are 3 solutions:

1. Your proposal above (works, but can use a
client-side software renderer only).  

2. Forget about a retained mode and ask the user to
specifically draw only the parts we need in a
callback(disadvantage: user must implement callback,
advantage: rendering can be hardware accelerated)

3. Forget about the transformation matrices: Implement
retained mode on a layer above cairo where we have
additional information.  For example in GTK we know
that we use either none or just a simple translation,
so we can tell _exactly_ what will be visible and what
not (disadvantage: dublicate API, advantage: user can
just draw without implementing a callback).


[ the following is an off-topic explanation of
longhorn surfaces and how they are used for
server-side animations ]

> I'm not even sure longhorn does incremental 
> modification of retained mode scene graphs 
> for animation. 

In longhorn there are essentially two interesting
"surfaces" (longhorn calls them "visuals"), a retained
visual and a drawing visual.

Both visuals maintain a scene graph.  The difference
between them is only that the drawing visual creates
the scene graph directly (usage: open, draw to it,
close. Equivalent to your proposal above #1) and the
retained visual forces you to draw only the parts that
are necessary (in a callback, see #2).  That means a
retained visual can be accelerated by the GPU while
the drawing visual is software-only.

All UI shapes derive from a retained visual and you
must implement the OnRender callback if you want to
create your own shape.  In other words all longhorn UI
elements can live on the server-side (GPU), maintain
their own graph and their state (transformation
matrix, alpha, ...) can be animated). Longhorn shapes
are equivalent to Cairo surfaces.

For example if you create your own shape which simply
draws a line from 0,0 to rand(),rand() in the OnRender
callback and then animate your shape -- by giving the
server a list of (time . transformation) pairs --, you
will see the animation running.  However, if you
re-size the window, you see the right end of the line
jumping around on the screen because your OnRender
drawLine has been updated the scene graph on the
server-side.

I have said above that a longhorn shape is like a
Cairo surface.  Well, it is more than that.  It also
defines the input (event-) area!  That means if you
apply a transformation (animation), the input window
is also transformed (animated).  





	

	
		
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 100MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de