[Webkit-unassigned] [Bug 105158] [Qt][WK1]REGRESSION(r137811): compositing/tiling/crash-huge-layer.html makes the following test crash on 32 bit

[bugzilla-daemon at webkit.org]

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


Paul Gideon Dann <pdgiddie+webkit at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pdgiddie+webkit at gmail.com




--- Comment #9 from Paul Gideon Dann <pdgiddie+webkit at gmail.com>  2013-11-25 08:00:07 PST ---
I'm working on a single-purpose Qt5WebKit-based browser for a web app we're developing, and I've run into a problem in WebCore that I'm pretty sure is related to this.  Please correct me if I'm wrong.

Essentially, when Google Maps is zoomed in quickly, you end up with a very, very large div before new tiles can be brought down to replace it.  During that time, when GraphicsLayerTextureMapper updates its backing store, the TextureMapperTiledBackingStore::createOrDestroyTilesIfNeeded() method attempts to allocate *massive* tiles, leading to allocation of several Gb of RAM, and the browser process gets killed by the kernel OOM killer.

I've dived into the code in the hope of finding a fix, and it seems to me that it should be possible to fix this by passing clipRect (which represents the size of the viewport, but is currently ignored) down from GraphicsLayerTextureMapper to the backing store, and restrict the area that is covered by tiles.

I'm having trouble, though, and I've clearly introduced painting bugs in the process, and am having trouble figuring out why.  Does anyone know if this is an approach that is doomed to failure because of some behaviour I'm unfamiliar with, or should this work in principle?

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