Re: Virtualizing paint functions

[Owen Taylor <otaylor redhat com>]

On Mon, 2006-04-10 at 19:53 +0200, Anders Carlsson wrote:
> Owen Taylor skrev:
> > Do you mean you want to *optionally* override it? That is, allow a
> > backend to override gdk_window_process_updates() but not 
> > process_all_updates()?
> >
> >   
> I didn't really want to have to modify the other backends in order to 
> support this, so if you don't need to override it you shouldn't need to.
> > Probably the easy thing to do would be have a default implementation
> > _gdk_window_process_all_updates() that backends could chain to, but
> > I'm not quite sure how maintenance of the list of dirty windows
> > would work if the backend has overridden invalidate_region() and
> > process_updates()
> >
> >   
> I guess one option is to keep a list of windows around and traverse it 
> in process_all_updates. Since we know (at least this is the case for OS 
> X) that the windows are invalidated when the window hits the main loop, 
> we could schedule an idle and just free the list in the idle. I think 
> that should be "Good Enough"...

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?

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?
						Owen