Re: Virtualizing paint functions

[Anders Carlsson <andersca imendio com>]

Owen Taylor skrev:
> 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?
>   
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.
> 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.

Anders