Re: Virtualizing paint functions



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

Yes, that should work just fine.
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.

That sounds like a good plan for the future if necessary, yes. I'm going to commit the latest patch I attached unless there's anything wrong with it.

Thanks,
Anders



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]