Bug 15070

Summary: [GTK] Backing store support for faster scrolling
Product: WebKit Reporter: Holger Freyther <zecke>
Component: New BugsAssignee: Nobody <webkit-unassigned>
Severity: Normal CC: alp, gwright, marco.barisione, withsmilo, zaheer.mot
Priority: P2 Keywords: Gtk, Performance
Version: 523.x (Safari 3)   
Hardware: Mac   
OS: OS X 10.4   
Description Flags
Initial implementation of a backbuffer none

Description Holger Freyther 2007-08-24 08:57:28 PDT
In order to implement multiple frame support the windows design was adopted. For the non static background we currently draw too much and too often.

On each scroll we are likely to redraw the whole viewport. ScrollView calls into the ChromeClient to update the backingstore and scroll the backing store which in the Gtk case are currently no-op's.
To change that the expose handler of WebKitGtkPage should just paint the backing store, ChromeClient should hold the backing store and to accelerate scrolling we should make sure to reuse as much as possible, and finally ScrollView should not invalidate the whole GdkWindow of the containingWindow() when the page is scrolled. To get/see/learn more details one should take a look at the windows port.

The interesting part is to decide how, where and what to buffer. E.g. disable double buffering on the GdkWindow, keeping a cairo surface in ChromeClient...

Another interesting observation is ScrollView::updateScrollbars which is creating and destroying PlatformScrollbars frequently on resizes.
Comment 1 George Wright 2007-12-11 08:58:42 PST
Created attachment 17848 [details]
Initial implementation of a backbuffer

This is an initial patch that doesn't work too well; scrolling vertically seems to be fine except for a few artifacts to do with text. However, scrolling horizontally seems to be a total failure.

Relevant code is in ChromeClient::scrollBackingStore() for those who wish to look at it. The cases for dy being <0 or >0 are fine; the analogous cases for dx do not work, and I'm not entirely sure why.
Comment 2 zaheer 2008-06-16 04:56:01 PDT
i think the problem is that frame->view()->paint is overwriting the other areas apart from the clip region. adding this clip to the cairo context as well seems to fix the problem..

+ ctx.clip(clip);
Comment 3 Marco Barisione 2008-06-20 03:41:24 PDT
Alp: on IRC you said that you have a semi-working patch for this. Any news? Do you want any help testing the patch?
Comment 4 Xan Lopez 2009-03-01 13:54:00 PST
I believe this is obsolete now since bug #21314 is in. Closing as.. FIXED (?).