Rumination on offscreen-ng

[Owen Taylor <otaylor redhat com>]

So, I spent some time today reading through Alex's offscreen-ng branch
today. My first question is how this is going to appear to the
application programmer and widget writers. The very existence of
GdkWindow at all is an imposition on the programmer .. after all,
widgets define the structure of your application, not windows.

It seems like we should have a single concept of GdkWindow that is as
simple as possible, have the programmer declare what features they need
for it:

 - Should the window have its own private offscreen storage?
 - Does the window have alpha transparency?
 - Is the window automatically drawn to the parent window?

And then GDK should go off and figure out how best to do that behind the
scenes.

(Unrelated idea: deprecate GdkWindowAttributes in favor of
g_object_new())

But looking more closely, there's another worry I have ... GdkWindow and
GdkVirtualWindow are a very tightly coupled base class and subclass.
Much of the logic for implementing virtual windows actually belongs to
the *parent* window, so GdkWindow needs special handling of 
GdkVirtualWindow children. I don't feel like the long term
maintainability of GDK is being improved.

I want to make a more radical proposal here: What if we consider the
client side window to be the basic concept and native windows to be an
elaboration of that.

So, GdkWindow would have all the code to:

 - Keep a clip region for the window
 - Clip rendering to that clip area
 - Implement window movement with gdk_draw_drawable()
 - Deliver events to the correct window

And so forth. Each GdkWindow would have a "target drawable" - basically
like the current window->impl - that could be:

 - A native GdkWindowImplFoo 
     (current GDK window)

 - The same native window as the parent window 
     (GdkVirtualWindow in offscreen-ng) 

 - A pixmap 
     (GdkOffscreenWindow in offscreen and offscreen-ng)

(Of course, it's not just a drawable, because you do need to do window
specific stuff to the native window when there is one.) 

Some consequences:

 - Invalid and damage regions are kept per native-target not per window.

 - It would then be very natural to have backends - directfb, maybe also
   Quartz that *just* implemented toplevel windows.

 - Since you keep the clip region for all windows, you could implement
   native children clipped by sibling "virtual" windows by setting a
   window shape. (Idea from alex)

 - If we wanted to switch a GdkWindow from virtual to native on the fly
   it would be pretty natural ... no change of class.


My instinct is that this would work out pretty cleanly - I won't say
simply.

- Owen