Darin, Peter, I'm digging up this thread because the current Mac behavior turns out to be problematic. Cocoa sets up the proper clipping region before calling drawRect:. We can't just expand the invalid rect and paint wherever we want, since Cocoa will ignore any drawing outside of the original invalid rect.
I've coded up another possibility: if we detect a recursive call to DidPaintRect(), defer the second paint until we return to the main loop and the first drawRect: is completed. This seems to work, but I'd like confirmation that it's ok to do the second paint asychronously. The code is up at http://codereview.chromium.org/335029/show . Does this look like something that will cause problems or race conditions? Thanks! Rohit On Mon, Apr 13, 2009 at 12:13 PM, Darin Fisher <[email protected]> wrote: > On Mon, Apr 13, 2009 at 8:43 AM, Avi Drissman <[email protected]> wrote: >> >> I'm still a little lost in this discussion. I'm repeatedly reading the >> code and the patch, and I'll get back to you when I fully understand it. But >> what I wanted to say is that there is a significant difference in the paint >> pipeline as it currently exists on the Mac compared to Win/Lin. >> >> On Win, DidPaintRect() calls Redraw() which calls >> RedrawWindow(...RDW_UPDATENOW...) which (AFAIK) does a synchronous draw via >> Win32 callback to OnPaint(). >> >> On Lin, DidPaintRect() calls Paint() which blits via >> BackingStore::ShowRect(). Again, synchronously. >> >> On Mac, DidPaintRect() calls Redraw() which calls -[NSView >> setNeedsDisplayInRect:], setting the damaged rect in the view. The call >> returns, and sometime later, during the next pump of the message loop, Cocoa >> wakes up, decides to repaint all damaged windows, calls our -drawRect:, >> which then calls RenderWidgetHost::GetBackingStore(). > > The Mac implementation is wrong. On a single core machine, the renderer > could starve the UI thread of the browser, preventing any pixels from ever > being updated on the screen. You need to change the Mac implementation to > flush to the screen when DidPaintRect is not called withing drawRect / > GetBackingStore. > Prior to Peter's change it was not possible for DidPaintRect to be called > from within GetBackingStore. Now that is possible, so the consumer needs to > take care. > -Darin > >> >> That gap prevents recursion. If for some reason GetBackingStore ends up >> causing a DidPaintRect() message, what will happen is: >> >> - Original DidPaintRect(), adds damage >> ... message loop ... >> - -drawRect: >> -- GetBackingStore() >> --- New DidPaintRect(), adds more damage >> -- blitting >> ... Cocoa clears the damage region, all of it >> >> Avi > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
