[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:38:23 PDT 2013
https://bugs.webkit.org/show_bug.cgi?id=122016
--- Comment #8 from Noam Rosenthal <noam at webkit.org> 2013-10-08 08:37:13 PST ---
(In reply to comment #7)
> (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 :)
Though if you were referring to the RLC/RLB patch, I totally agree.
--
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