[Webkit-unassigned] [Bug 14857] [gtk] ScrollView and WebKitGtkPage changes to make multiple frames possible

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=14857





------- Comment #10 from freyther at handhelds.org  2007-08-03 05:12 PDT -------
(In reply to comment #9)
> Some of these patches introduce slightly strange scrolling behaviour (the
> content is slow at keeping up with the position of the scrollbar), and possibly
> an impact on performance.

Sure. This is the nature of the "Implement ScrollView" change. In contrast to
GtkLayout we can not create this big GdkWindow anymore and can't use
gdk_window_move which was so good for scrolling. As described when originally
posting this patch there are hooks to ChromeClient to update the backing store
and to do the scrolling. It is matter of using gdk_window_scroll_by or similiar
method and reducing the exposing region to accelerate scrolling again but these
are not yet implemented. For now to always keep up with scrolling you could
force gdk to deliver the expose events (gdk_window_process_updates), probably
in ScrollView::updateScrollbars or in the methods calling it
(ScrollViewPrivate::valueChanged, ScrollViewPrivate::adjustmentChanged).


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