On Mon, Apr 13, 2009 at 11:28 AM, Adam Langley <a...@chromium.org> wrote:
> It's not that don't want to deal with this right now, it's that I
> believe that the current behaviour is correct on Linux.
Yes, I grasped that.
I've reread
> your patch and email and I haven't understood any arguments about why
> there's a problem. (I get that there might be something about the
> priority of Windows WM_PAINT messages that causes an issue, but that
> obviously doesn't apply with X.)
>
The reason I had to write a patch at all is a cross-platform issue, not a
Windows-specific one. The Windows-specific stuff in the comments is merely
an example of why an API like DidPaintRect() is useful in the first place,
but we're not adding that API in this patch, just explaining what's going
on.
The issue I'm fixing is that if we get an updated rect from the renderer
while DidPaintRect() is disabled, we don't repaint any extra damaged area in
that rect until the next time it happens to get damaged, because we don't
send anyone any notifications. This is because we were putting in an
anti-recursion check in the "model" when instead it should have been in the
"view".
Fixing this means that any platform that (correctly) synchrously paints from
DidPaintRect() is now at risk of infinite recursion, and the new DCHECK is
designed to detect this. It fires on Linux because Linux was doing the
right thing before; it doesn't fire on Mac and at some point Avi will fix
the Mac implementation.
To fix _this_ issue the platform-specific code needs to have its own
anti-recursion check, as Windows now has. This is what I'm asking Linux to
write. You write one by detecting (inside DidPaintRect()) that you're
already in a paint and not recursively painting again.
PK
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
