[Webkit-unassigned] [Bug 45423] [Gtk] Port tiled backing store

[bugzilla-daemon at webkit.org]

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





--- Comment #51 from Joone Hur <joone at kldp.org>  2011-03-06 23:03:42 PST ---
(In reply to comment #50)
> (From update of attachment 81801 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=81801&action=review
> 
> > Source/WebKit/gtk/WebCoreSupport/ChromeClientGtk.cpp:389
> > +#if ENABLE(TILED_BACKING_STORE)
> > +        Frame* frame = core(m_webView)->mainFrame();
> > +        if (frame && frame->tiledBackingStore())
> > +            frame->tiledBackingStore()->invalidate(updateRect);
> > +#endif
> 
> While trying integrating this work on the clutter port I found out that this is wrong and makes babies cry. This is precisly the method the backing store uses to let WebKit know it should update the view from the backing store contents when it's done painting, so invalidating the backing store here causes us to enter an infinite loop. It does not lock up in a tight loop simply because the backing store uses a timer to process updates, and delays them for a few ms, but it's easy to see the problem given the CPU usage being high and responsiveness decreasing over time.

I added this code to fix the following issue:

https://bugs.webkit.org/show_bug.cgi?id=45423#c25
> I've tested it and seen some visual issues: the left upper tile is not cleaned in some situation when loading a new page (search in google, open a webpage), scrolling has some issues in slashdot with the floating bar in the bottom.

However, it has the critical performance issue as Kov has commented, so I will remove it. Thanks Kov for reporting this issue.

Anyway, the above visual issues seems to be appeared because of erasing the content during loading a new page on WebKitGtk+. On the other hand, other ports don't erase the content before painting a new page. 
Otherwise, we have to stop painting the backing store when loading a new page.

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