Re: Virtualizing paint functions

[Anders Carlsson <andersca imendio com>]

Owen Taylor skrev:
> 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. 
>
>   
Ah, that looks way better that the hack I had. When I was looking at 
inheritance, I was concerned with not being able to provide a default 
implementation.

I guess the remaining issue now is how to override 
gdk_window_process_all_updates, without requiring copies of the function 
in the different backend implementations.

> 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...
>   
>   
Yes, I've got the clip region management implemented and it seems to 
work well.

Regards,
Anders