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.
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.
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.setGdkBackingStore(GDK_DRAWABLE(pageData->backingStore)); + ctx.clip(clip);
Alp: on IRC you said that you have a semi-working patch for this. Any news? Do you want any help testing the patch?
I believe this is obsolete now since bug #21314 is in. Closing as.. FIXED (?).