| Summary: | [Gtk] scrolling artifacts | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | zaheer <zaheer.mot> | ||||||
| Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Normal | CC: | abarth, alex, cgarcia, commit-queue, eric, mrobinson, webkit.review.bot, xan.lopez, zecke | ||||||
| Priority: | P2 | ||||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Attachments: |
|
||||||||
This is basically responsibility of the gtk scrolling code, since clien-side-windows patches situation is not that bad if you do not have a native window in the view. Basically if you have a plugin with window, the scroll fallback to the old behaviour, which is this. We would like to work on this and trying to fix it with a backing store, it is interesting wrt webkit2. (In reply to comment #1) > This is basically responsibility of the gtk scrolling code, since clien-side-windows patches situation is not that bad if you do not have a native window in the view. Basically if you have a plugin with window, the scroll fallback to the old behaviour, which is this. We would like to work on this and trying to fix it with a backing store, it is interesting wrt webkit2. Do you mean a backing store on the server (xpixmap) since i think plugins use x windows directly. Also in the current situation, isnt it possible to postpone the window move to a later point (expose) and draw everything at once. Created attachment 76760 [details]
Patch to call gdk_window_process_updates() when scrolling
Yes, calling gdk_window_process_updates() fixed the artifacts for me. Maybe there are other performance issues to fix, but we should definitely call gdk_window_process_updates() right after moving the window when scrolling, it's what all gtk widgets that implement scrollable interface do, see GtkLayout, GtkViewPort, GtkTextView, etc.
Comment on attachment 76760 [details]
Patch to call gdk_window_process_updates() when scrolling
Great catch.
Comment on attachment 76760 [details] Patch to call gdk_window_process_updates() when scrolling Rejecting attachment 76760 [details] from commit-queue. Failed to run "['./WebKitTools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=cr-jail-3', 'apply-attachment', '--non-interactive', 76760]" exit_code: 2 Last 500 characters of output: ailed to merge in the changes. Patch failed at 0001 2010-12-16 Yury Semikhatsky <yurys@chromium.org> When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To restore the original branch and stop rebasing run "git rebase --abort". rebase refs/remotes/origin/master: command returned error: 1 Died at WebKitTools/Scripts/update-webkit line 132. Failed to run "['WebKitTools/Scripts/update-webkit']" exit_code: 2 Full output: http://queues.webkit.org/results/7076078 Committed r74196: <http://trac.webkit.org/changeset/74196> http://trac.webkit.org/changeset/74196 might have broken Leopard Intel Debug (Tests) |
Created attachment 66183 [details] scroll artifacts scrolling causes artifacts. This is possibly because the expose is not triggered fast enough after moving the partial window in chromeclient::scroll. A fix could be to force an update gdk_window_process_updates but thats likely a performance hit. chrome+linux has a faster scroll speed something i guess we need to match on the gtk port. snap attached