On Fri, Apr 10, 2009 at 1:07 PM, Adam Langley <a...@chromium.org> wrote:
> X sends an expose message to us
> We ask for a BackingStore
> We don't have one, so we start a timed wait on the renderer to send us a
> paint
> We get the paint, so we create the backing store and copy the bitmap to it.
> With your patch:
> We then call back into GTK to invalidate the rect again! Error!
The question is, has GTK already validated the rect it sent us to paint? If
so, we should just enlarge the rect that the paint function will redraw; if
not, we should both do that and ensure that that larger rect gets validated.
(On Windows, the case is the latter.) In neither case do we really want to
come out of painting with a dirty rect from this.
Your comment suggests that you want to do more than invalidate in
> DidPaintRect because of WM_PAINT starvation. I don't get how this
> helps you. In the case that you're talking about, we're dealing with a
> message from the renderer without the expose handling on the stack and
> then that guard that you removed doesn't even come into play.
When you paint, the paint function will ask for the updated backing store,
which potentially needs to go to the renderer and wait (if it is dirty).
When it comes back, with the guards removed, you call DidPaintRect(), which
calls Paint(), which can recurse because the backing store may still need
updating (e.g. we got an ack of a previous resize but another is waiting, or
similar). Darin came up with some thought experiments in which this
recursion happens effectively infinitely. On the other hand, if you fix
this by making DidPaintRect() not paint, then you'll invalidate the area,
but potentially never get a paint callback unless your event system
guarantees that you'll paint within a certain period no matter how much the
renderer is eating the CPU and spamming you with updates.
In short, DidPaintRect() painting rate-limits the renderer from starving
paints, and being clever about how we paint and invalidate prevents infinite
recursion and/or overpainting during this.
I strongly suggest picking Darin's brain directly for more detail as he has
a stronger grasp of this than I do :)
PK
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
