WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
15070
[GTK] Backing store support for faster scrolling
https://bugs.webkit.org/show_bug.cgi?id=15070
Summary
[GTK] Backing store support for faster scrolling
Holger Freyther
Reported
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.
Attachments
Initial implementation of a backbuffer
(7.82 KB, patch)
2007-12-11 08:58 PST
,
George Wright
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
George Wright
Comment 1
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.
zaheer
Comment 2
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.setGdkBackingStore(GDK_DRAWABLE(pageData->backingStore)); + ctx.clip(clip);
Marco Barisione
Comment 3
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?
Xan Lopez
Comment 4
2009-03-01 13:54:00 PST
I believe this is obsolete now since
bug #21314
is in. Closing as.. FIXED (?).
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug