subwindow-less Gtk+ and offscreen windows

If I were designing a toolkit today I would definitely make it not use
subwindows, and if we're breaking ABI/API in Gtk+ 3.0 it would be nice
to look into how we could do this in Gtk+.

I've been thinking about this a bit recently in my copious spare time
(ha ha). Not using subwindows means not using X sub windows to get
events and clipping for widgets. There are a couple of advantages in
* Window resizes is much smoother since you only have to resize the
top level window and then you can immediately draw the full result,
instead of asynchronously resize all child window and sometimes get
partial results drawn.
* Portability is much easier, since you rely less on the details of
the native handling of events and subwindows.
* The API for implementing a widget could be simplified as you don't
have to handle realize/unrealize in such a complicated way (or at
* It is possible to handle drawing of overlapping widgets in a better
way. For instance, you may allow a partially overlapping widget to
show through the widget over it, or allow non-axis-aligned-rectangle

After a while I realized that even if you're not using server side X
subwindows you need a similar structure on the client side, so that
a widget can specify that it wants clipping and event delivery for a
certain area, etc. I also realized that my previous work on offscreen
windows and redirection almost implements this already.

The (full) offscreen window patch works by implementing a different
type of GdkWindow (called GdkOffscreenWindow), and allowing you make
such a window a child of a "real" native window. This automatically
causes subwindows of that window to become
GdkOffscreenWindows. GdkOffscreenWindows manually implement both
clipping according to the (client side) window hierarchy and event
delivery, and actual drawing is proxied into the topmost non-offscreen

Here is the insight: If you were to make the toplevel window a native
window and all child windows GdkOffscreenWindows you would get an
subwindow-less Gtk+ which is quite backwards compatible. The only
thing that wouldn't work is that you can't get the native xid of any
child window (there isn't any). This leads to a bunch of problems
(that also exist for the offscreen windows work):

* 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.
* some input methods (xim?) needs an x id (I think)
* There are some weird things you can do in X like having different
  visuals and depth in different windows. For instance, some servers
  support both 24bit and 8bit visuals on the same screen. Its not
  really possible to support this with client side windows.
* GtkPlug/GtkSocket and any other kind of out-of-process embedding
  really requires a native X window to pass to the embedding process.
I can think of some possible solutions to this. For instance, we could
lazily instantiate the X windows such that we don't create them until
we really need to, and when we need it we create all parent windows at
once. This means that such windows won't be able to get any extra
features like see-through windows etc, but this will be an uncommon
case. It sounds kind of complex though, and it makes it hard to get
the "portability" advantage I listed above.

I really like this idea and I want to throw it out there so that
people working on Gtk 3.0 and the offscreen patches have this in mind,
even if I don't have any time to work on this myself ATM.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]