Re: Virtualizing paint functions

[Owen Taylor <otaylor redhat com>]

On Mon, 2006-04-10 at 20:18 +0200, Anders Carlsson wrote:
\
> > I'm basically not following what you are talking about at all, I think
> > I missed a step earlier :-(
> >
> > Right now, you have a bunch of the functionality diverted to the
> > GdkPaintable interface, but not process_all_updates(), right?
> > So if you implement GdkPaintable on your window implementation, 
> > process_all_updates() does nothing because nothing is added to
> > the dirty list?
> >   
> Yeah, that's right, and currently this is not a problem because the only 
> place (in gtk+) where process_all_updates() is being called is in an 
> idle function (scheduled by the standard invalidate_region() function), 
> and for Quartz the invalidated regions will automatically be redrawn in 
> the main loop.

And at that point you generate expose events and call GTK+'s event 
function?

Does that also trigger if someone does

 while (g_main_context_pending (NULL))
   /* nothing */ ;

as if trying to get things to update while doing something intensive?

> > What would be the problem of making process_all_updates() part of
> > GdkPaintable? I don't think it is worth worrying about the case
> > where a backend wants to implement everything else in GdkPaintable
> > and not that ... we have *zero* examples of such a backend,
> > right?
> >   
> The problems is that gdk_window_process_all_updates doesn't take an 
> argument, so there is no object passed in which can implement GdkPaintable.

Ah. May not be worth fixing the problem until a need arises, but if 
you wanted to do so, an optionally null function on GdkDisplay seems
easiest ... then the current function could just walk over open
displays.

Regards,
						Owen