Re: Virtualizing paint functions

[Owen Taylor <otaylor redhat com>]

On Mon, 2006-04-03 at 23:30 +0200, Anders Carlsson wrote:
> Hello,
> 
> for the Quartz backend I'd like to use the native versions of some 
> things GTK+ normally provides. These are:
> 
> * Double buffering (gdk_window_begin/end_paint)
> 
> * Invalidating regions (gdk_window_invalidate_region, 
> gdk_window_process_updates)
> 
> In order to do that I'd like to make it possible to replace some of the 
> functions. I currently have a patch that adds a function call:
> 
> void _gdk_set_paint_functions (GdkBeginPaintRegionFunc       
> begin_paint_region,
>                    GdkEndPaintFunc               end_paint,
>                    GdkInvalidateMaybeRecurseFunc invalidate_maybe_recurse,
>                    GdkProcessUpdatesFunc         process_updates,
>                    GdkProcessAllUpdatesFunc      process_all_updates);
> 
> which lets backends (this is for obvious reasons NOT a public API) 
> provide their own implementations of some functions.
> 
> I'd like to hear opinions on this from other backend maintainers.

Not a backend maintainer at the moment, but as for the virtualization
technique, blech!

We have two major ways of virtualizing functionality in backends:

 - Providing entry points that backends must implement
 - Derivation

The current stuff is in no way clean, consistent, or simple, but
introducing  runtime customization like the above is *not* going to
improve that. I haven't really thought through the problem, but one
possible way of doing it would be to make the invalidation system an
optional interface on the impl drawable.

So:

 if (GDK_IS_PAINTABLE(window)->impl)) 
   {
     GDK_PAINTABLE(impl)->invalidate_region(region);
     return;
   }

 [ Current implementation ]

That *is* another way of doing backend customization from what we have
as well, but at least it's a way that fits into the general GObject
patterns. 

Have you considered what part of the documented behavior for nested
calls to begin_paint() you'll be able to achieve using the OS X native
facilities? You'll presumably need some creative management of clip
regions...
  
    					  Owen