[Webkit-unassigned] [Bug 92196] ASSERTION FAILED: !needsLayout() : virtual void WebCore::RenderView::paint(WebCore::PaintInfo &, const LayoutPoint &)

[bugzilla-daemon at webkit.org]

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





--- Comment #4 from Zalan Bujtas <zbujtas at gmail.com>  2012-10-01 05:24:26 PST ---
It looks like when WebTiledLayer (inherited from CATiledLayer) is used to render the content, painting operation is not guaranteed to happen on a clean tree. 

what normally happens with a CALayer based surface rendering
1, js initiates layout change and layout is scheduled 
2, layout is executed
3, painting is initiated by calling TiledCoreAnimationDrawingArea::flushLayers()
4, flush calls WebTiledLayer::setNeedsDisplayInRect() (and it also calls layoutifneeded to make sure of a clean tree)
5, in setNeedDisplayInRect, CATiledLayer schedules a callback to ::display to render the content -presumably with a 0 timer to make sure no other timer can be fired between this and rendering -like a js timer to change content) 
6, ::display is called and it directly calls into ::drawInContext ->rendering
7, js initiates layout change...   

and how it is different from a CATiledLayer based surface rendering (now that the content height is over 2000px)
1, js initiates layout change and layout is scheduled 
2, layout is executed
3, painting is initiated by calling TiledCoreAnimationDrawingArea::flushLayers()
4, flush calls WebTiledLayer::setNeedsDisplayInRect() + layoutifneeded
5, in setNeedDisplayInRect, CATiledLayer schedules a callback to ::display
6, ::display is called but it does not call into ::drawInContent synchronously, instead it looks like it schedules a callback to it.
7, js initiates layout change and layout is scheduled 
8, ::drawInContext is called on a dirty tree -> assert.

so apparently js can get a timeslot between flush and the actual rendering and that breaks the rule of rendering always on a clean tree. 
According to the CATiledLayer documentation, due to the potentially large(r) size of rendering surface, there could be multiple calls made to render the content. I assume this 'multiple call' manner leads to the asynchronous way of initiating ::drawInContent. We should either not let any other timer fired inbetween(CA code?) or make sure right before the rendering that the content is still clean(yet another layout). (or drop the CATiledLayer completely)
Not sure if all above holds true as I've got no access to Core Animation sources, so someone with access should check this out.

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