Re: Rumination on offscreen-ng

[Owen Taylor <otaylor redhat com>]

On Wed, 2008-11-19 at 10:18 +0100, Alexander Larsson wrote:
> On Tue, 2008-11-18 at 16:28 -0500, Owen Taylor wrote:
> > Some consequences:
> > 
> >  - Invalid and damage regions are kept per native-target not per window.
> 
> What exactly do you mean by this btw? Do you mean moving  the current
> GdkWindowObject->update_area somewhere so it affects the native window?
> We could do that, although it would require some restructuring of how we
> handle updates. However, its not strictly necessary just because we push
> GdkVirtualWindow into GdkWindow. 

I'm not really proposing an implementation technique; there are various
things that could be done:

 - Making all native windows implement GdkPaintableIface, perhaps with
   a helper object that can be chained to for the default
   implementation. (This might imply that you'd need a PaintablePixmap
   object for GdkOffscreenWindow.)

 - Have a GdkPaintInfo object that is referenced in parallel to the
   drawable target from each GdkWindow.
 
But the simplest thing is just to ignore the fields in GdkWindow unless
the window has its own drawable target.

> Its got some advantages, for instance we will automatically never keep
> update areas for invisible areas. But it also causes some added
> complexities. For instance, when moving a subwindow that has some
> invalid area we currently just keep that, which is right because its in
> window relative coordiantes. If we keep that update area on the parent
> window we need to do some complex updates on the parents update_area in
> order to move the invalid area of the subwindow with the subwindow.

Well, the approach of keeping the invalid region on the topmost window
for the drawable target is pretty much forced for the case when the
drawable target implements GdkPaintableIface... that is, if the invalid
region is stored inside the windowing system, we can't create a separate
one for a subwindow.

Another consideration that I had in mind was your idea of having windows
with a "parent" background ... where you don't clip the parent with the
child and always redraw the parent before redrawing the child. That's
less of a special case if you share invalid regions.

The idea of moving portions of the invalid region along with the child
bits sounds complex, but it's really a pretty simple exercise in region
arithmetic. And it's one that we've already done! See the code in
gdkgeometry-x11.c:_gdk_x11_window_move_region()

- Owen