[Webkit-unassigned] [Bug 122016] [CoordinatedGraphics] ASSERTION FAILED: !m_flushingLayers (after r156291)

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Oct 8 08:37:47 PDT 2013


https://bugs.webkit.org/show_bug.cgi?id=122016





--- Comment #7 from Noam Rosenthal <noam at webkit.org>  2013-10-08 08:36:38 PST ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > > (In reply to comment #1)
> > > > > It is incorrect to call scheduleLayerFlush() inside of flushCompositingState().
> > > > 
> > > > Is any attempt to reenter RenderLayerCompositor considered incorrect at that point?
> > > > In other words, could a simple check whether a flush is underway inside any implementation of GraphicsLayerClient::notifyFlushRequired() (like in this very case) be considered a right step?
> > > 
> > > Heh, I was going to attempt something like that: https://gist.github.com/qrwteyrutiyoup/647d9ca085b2dc13d1d7
> > > 
> > > To prevent calling scheduleLayerFlush() inside flushCompositingState(),         which is incorrect, we now only call m_client->notifyFlushRequired() --         which will trigger scheduleLayerFlush() -- if we are not already flushing         layer changes.
> > 
> > I think this is a good approach.
> 
> The fix should be in your GraphicsLayer implementation, not up in RLB/RLC, so I think that approach is OK.
> 
> The reason it's an error to do this is that there's ambiguity about whether doing this would trigger a later flush, or just get dropped.

This ambiguity can maybe fixed by proper naming. I think if I see a patch with this approach with r? we can discuss the naming :)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list