[Webkit-unassigned] [Bug 93036] [BlackBerry] Add GraphicsLayerClient::contentsVisible()

[bugzilla-daemon at webkit.org]

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


Arvid Nilsson <anilsson at rim.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[BlackBerry] Accelerated    |[BlackBerry] Add
                   |compositing checkerboard    |GraphicsLayerClient::conten
                   |never resolves              |tsVisible()




--- Comment #2 from Arvid Nilsson <anilsson at rim.com>  2012-08-02 16:05:07 PST ---
Whoa, I discovered contentsVisible isn't even upstreamed yet. How about this?

LayerTiler uses both proactive and reactive rendering to populate tiles. If contentsVisible() is accurate, it will cause the right tiles to be rendered. Failing that, when a dirty tile is found to be visible on the compositing thread, a render job is scheduled.

Returning true by default would cause memory usage to balloon, because the LayerTiler would believe every tile is visible and always needs to be rendered. Instead, we choose to return false by default, relying entirely on reactive rendering unless the client reimplements this method.

However this revealed a subtle bug. If the entire layer was invalidated every frame, checkerboard would never resolve.

Fixed by not clearing visibility jobs when the entire layer is invalidated, thus making us robust against an incomplete contentsVisible implementation.

Also removed dead code related to the deprecated LayerTiler::m_tilesWebKitThread mechanism, which has been replaced by the new visibility handling described here.

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