Bug 25696 – gtk directfb screen corruption on scrolling of webview

• Component: WebKitGTK
• Status: RESOLVED INVALID

[Luke Kenneth Casson Leighton]

got a bit of an issue with a directfb gtk app, using a gtk ScrollWindow and a webkit webview widget embedded in it.  mouse and keyboard scroll events give screen corruption when using VESA, IntelFB and also an embedded device (exact details unknown to me).  the amount and nature of the screen corruption that occurs is dependent on how much of the display area is being scrolled (by the mouse or the keyboard) but it varies from black artefacts, blue artefacts, both of width of the entire screen, and clearly distinguishable portions of the web page being viewed being shifted vertically by random offsets.

the corruption DOES NOT occur if:

* the vertical scrollbar position is set _manually_ using value adjustment on the scrollbar:
   m_VerticalAdjustment =
        gtk_scrolled_window_get_vadjustment(
             GTK_SCROLLED_WINDOW(scrolled_window));
   gtk_adjustment_set_value(m_VerticalAdjustment, val + INCR);

* the application is compiled as an X-Windows gtk app.  under these circumstances, no screen corruption occurs at all.


dpkg -l | grep directfb
ii  libcairo-directfb2                   1.8.6-2+b1                           The Cairo 2D vector graphics library DirectFB build (d
ii  libcairo-directfb2-dev               1.8.6-2+b1                           Development files for Cairo graphics library DirectFB 
ii  libdirectfb-1.2-0                    1.2.7-2                              direct frame buffer graphics - shared libraries
ii  libdirectfb-dev                      1.2.7-2                              direct frame buffer graphics library - development fil
ii  libdirectfb-extra                    1.2.7-2                              direct frame buffer graphics - extra providers
ii  libgtk-directfb-2.0-0                2.14.7-5                             The GTK+ graphical user interface library - DirectFB r
ii  libgtk-directfb-2.0-dev              2.14.7-5   


confirmed, also: the standard GtkLauncher application also shows the
exact same screen corruption on scrolling, using mouse or keyboard.
yet, the same GtkLauncher app when compiled using X-libs is fine.

[Luke Kenneth Casson Leighton]

also related #22540 which also has screen corruption under gtk-directfb.

[Luke Kenneth Casson Leighton]

Created attachment 30393 [details]
switches off fine-tuned paint logic, draws whole view, properly

thanks to paul for the guidance and for the leading work / patches on which this is based, paul, the code that you sent me has a bug where the scrollbars on a frame will go "blank" and disappear when you move the mouse over them. the reason is that the empty rect causes the return out of the paint function, prematurely, i fixed this by allowing the scrollbars always to be painted.

[Dave Hyatt]

Umm why does this have a + on it?  There's nothing wrong with this cross-platform code, and you're changing other platform behavior.

[Dave Hyatt]

Also, please don't mark bugs as reviewed if you are not a reviewer.  I'll give you the benefit of the doubt and assume you meant to set it to ? instead.

Anyway this patch is no good, since it just turns off blitting on scrolling completely.  This isn't something you should have to do.  All you're doing is working around bugs in your port's blitting implementation by doing this when you should be fixing those bugs.

The code that clips is also unnecessary.  As I said on webkit-dev, it is the responsibility of WebKit to clip to the document dirty rect before you even get into ScrollView paint.  Because you can have nested ScrollViews, repeatedly clipping to the document dirty rect is not something that these ScrollViews should need to do.  

Clipping to the visibleContentRect is necessary for each subframe ScrollView because the dirty rect may partially overlap the frame, but clipping to the document dirty rect should not be needed, as it should only happen once.  It is the WebView's responsibility to do this clipping in your WebKit port.

[Dave Hyatt]

If it turns out your port has buggy blitting and you don't plan on solving the underlying problem, then in your platform-specific code you can always just set the can blit on scroll flag on the ScrollView to false.  That is the best way to disable all blitting without touching the cross-platform code.  Your scrolling performance is not going to be very good, though, if you do this, so I encourage you to try to figure out what is actually wrong with the underlying platform-specific blitting code (a bug in Cairo perhaps?).

[Luke Kenneth Casson Leighton]

sorry, dave, i clicked the wrong button.

also - apologies, i do not know the difference between cross-platform code and other platform code.

all i know is that this works, and fixes a really serious show-stopper problem.  just disabling the blitting (with the #if 0) does not fix the problem.

it is unfortunately completely impractical to go digging around in gtk-directfb, it's _way_ too complex and time-consuming.

so - a minus review means it's unacceptable, and will thus remain unfixed.

for those people who will be searching desperately on the internet for ways to get their code out the door, and who do not have time to go fixing up gtk-directfb blitting bugs, or to find out what the bloody hell is going on, try this patch: disable the blitting, and also the bit which changes the rectangles.

i don't understand how it works, and i don't care: i just know that it works.  if you don't add the bit which changes the rectangles, you end up with one "flicker" (screen corruption) when you initially start scrolling a Frame, but only when both the horizontal and vertical scrollbars are both at 0, 0 scroll position.

thereafter, there is no further screen corruption, but even that one incident is too much.

patch the rectangles / clipping as shown in this patch and you will get no more flicker.


dave: paul has already mentioned that there is something wrong with the rectangle / clipping.

thank you for mentioning about the setting in scrollview, that will help other people.

right now, we have the solution, and there is not enough time or money to go hunting through a complex set of code like gtk-directfb or cairo-directfb.

so if anyone else would like to follow up on this, this patch highlights where the problems are, and at least provides a decent interim workaround.

[Anders Carlsson]

Sounds like this is a bug in the DirectFB GTK+ backend.