Re: subwindow-less Gtk+ and offscreen windows

[Alexander Larsson <alexl redhat com>]

On Mon, 2008-08-04 at 09:53 -0700, Mathieu Lacage wrote:
> On Mon, 2008-08-04 at 12:22 +0200, Alexander Larsson wrote:
> > On Sat, 2008-08-02 at 21:35 +0200, Alexander Larsson wrote:
> > 
> > > * Some operations require an X window id, for example:
> > >    + glXMakeCurrent()
> > >       so that you can draw into a window with opengl.
> > >       You can still draw to the toplevel window, but you can't
> > >       have GdkOffscreenWindow automatically clip the opengl drawing
> > >       calls (i think).
> > >    + the Xv extension
> > >       If you want to show video in a part of your window you need
> > >       to use Xv, and you have to give it a subwindow in which to
> > render.
> > 
> > Qt changed over to not use subwindows in 4.4.0 I believe. It would be
> > interesting to see how they solved problems like these.
> 
> It would be nice if you could point out why the very naive solution
> which uses a special Gtk/Gdk container widget with an X sub window would
> not work in this case. Would it not be backward compatible
> (source-level ?). Or would this not allow you to get the simplification
> benefits you described earlier because it would force you to keep all
> the x subwindow machinery ?

It wouldn't work because the parent client-side subwindows of that
window doesn't exist in the server, so can't be set as the parent. One
could of course set the parent to be the toplevel window, but this means
you won't get the behaviour you expect (i.e. clipping and scrolling as
per the window hierarchy, and correct painting of other overlapping
client-side windows). It would work in many cases, but not for instance
if the widget is packed in a GtkScrolledWindow (and scrolled).