Re: Some 2.6 thinking
- From: Juhana Sadeharju <kouhia nic funet fi>
- To: gtk-devel-list gnome org
- Subject: Re: Some 2.6 thinking
- Date: Tue, 27 Apr 2004 16:25:53 +0300
>From: Bill Haneman <Bill Haneman Sun COM>
>Probably what you want is the COMPOSITE X extension, which is
[ ... ]
>For a lot of reasons,
>it's better to do this with server-side support as opposed to just
>rendering widgets offscreen in the client library.
Hello. I will check the freedesktop soon; I missed that in my recent
search for various similar and related software.
I'm still confused.
If GTK2 already renders widgets to offscreen pixmaps (for flicker
reduction), then would it be easier to read those offscreen
pixmaps and render them differently to the screen? Can GTK2 widgets
be made to render to the offscreen pixmaps but not to the screen?
I would then provide the screen rendering in my routines, and
my routines would deliver events from/to the offscreen widgets.
I don't need GTK2 widgets to have the alpha channel because I could
provide the alpha channel and the transparency externally in my
People have written that reading pixmaps from server/hardware
is slow. Are GTK2's offscreen widgets located at server/hardware
or in motherboard RAM?
Does freedesktop merge X widgets and OpenGL widgets? One event &
callback system? In X side the widgets would be the normal widgets,
but in OpenGL side the widgets would be 3D objects and primitives.
If the 3D ray from pointer to the scene hits an object, then a
focus-in event is send. Motion notify is send if the ray keeps
intersecting the object. If object is a hierarchy of 3D objects,
then each object is further tested for events (like subwindows in X)
if they have callbacks. Something like that would be good in GTK,
of course. As common as possible widget API for both X and OpenGL.
] [Thread Prev