25696 2009-05-11 09:22:36 -0700 gtk directfb screen corruption on scrolling of webview 2015-04-24 11:52:33 -0700 1 1 1 Unclassified WebKit WebKitGTK 528+ (Nightly build) PC Linux RESOLVED INVALID Gtk P2 Normal --- 0 lkcl webkit-unassigned andersca oldest_to_newest 120672 0 lkcl 2009-05-11 09:22:36 -0700 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. 120684 1 lkcl 2009-05-11 09:47:48 -0700 also related #22540 which also has screen corruption under gtk-directfb. 121532 2 30393 lkcl 2009-05-15 10:13:22 -0700 Created attachment 30393 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. 121538 3 hyatt 2009-05-15 10:27:12 -0700 Umm why does this have a + on it? There's nothing wrong with this cross-platform code, and you're changing other platform behavior. 121539 4 hyatt 2009-05-15 10:36:50 -0700 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. 121540 5 hyatt 2009-05-15 10:47:30 -0700 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?). 121542 6 lkcl 2009-05-15 10:51:29 -0700 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. 1088284 7 andersca 2015-04-24 11:52:33 -0700 Sounds like this is a bug in the DirectFB GTK+ backend. 30393 2009-05-15 10:13:22 -0700 2010-06-10 17:10:50 -0700 switches off fine-tuned paint logic, draws whole view, properly f text/plain 2583 lkcl ZGlmZiAtLWdpdCBhL1dlYkNvcmUvcGxhdGZvcm0vU2Nyb2xsVmlldy5jcHAgYi9XZWJDb3JlL3Bs YXRmb3JtL1Njcm9sbFZpZXcuY3BwCmluZGV4IGYyZDFlNTUuLmQxY2NkMjkgMTAwNjQ0Ci0tLSBh L1dlYkNvcmUvcGxhdGZvcm0vU2Nyb2xsVmlldy5jcHAKKysrIGIvV2ViQ29yZS9wbGF0Zm9ybS9T Y3JvbGxWaWV3LmNwcApAQCAtNDA4LDE0ICs0MDgsMTggQEAgdm9pZCBTY3JvbGxWaWV3OjpzY3Jv bGxDb250ZW50cyhjb25zdCBJbnRTaXplJiBzY3JvbGxEZWx0YSkKICAgICAgICAgaG9zdFdpbmRv dygpLT5yZXBhaW50KHBhblNjcm9sbEljb25EaXJ0eVJlY3QsIHRydWUsIHRydWUpOwogICAgIH0K IAorI2lmIDAKICAgICBpZiAoY2FuQmxpdE9uU2Nyb2xsKCkgJiYgIXJvb3RQcmV2ZW50c0JsaXR0 aW5nKCkpIHsgLy8gVGhlIG1haW4gZnJhbWUgY2FuIGp1c3QgYmxpdCB0aGUgV2ViVmlldyB3aW5k b3cKICAgICAgICAvLyBGSVhNRTogRmluZCBhIHdheSB0byBibGl0IHN1YmZyYW1lcyB3aXRob3V0 IGJsaXR0aW5nIG92ZXJsYXBwaW5nIGNvbnRlbnQKICAgICAgICBob3N0V2luZG93KCktPnNjcm9s bCgtc2Nyb2xsRGVsdGEsIHNjcm9sbFZpZXdSZWN0LCBjbGlwUmVjdCk7CiAgICAgfSBlbHNlIHsg CisjZW5kaWYKICAgICAgICAvLyBXZSBuZWVkIHRvIGdvIGFoZWFkIGFuZCByZXBhaW50IHRoZSBl bnRpcmUgYmFja2luZyBzdG9yZS4gIERvIGl0IG5vdyBiZWZvcmUgbW92aW5nIHRoZQogICAgICAg IC8vIHBsdWdpbnMuCiAgICAgICAgaG9zdFdpbmRvdygpLT5yZXBhaW50KHVwZGF0ZVJlY3QsIHRy dWUsIGZhbHNlLCB0cnVlKTsgLy8gSW52YWxpZGF0ZSB0aGUgYmFja2luZyBzdG9yZSBhbmQgcmVw YWludCBpdCBzeW5jaHJvbm91c2x5CisjaWYgMAogICAgIH0KKyNlbmRpZgogCiAgICAgLy8gVGhp cyBjYWxsIHdpbGwgbW92ZSBjaGlsZHJlbiB3aXRoIG5hdGl2ZSB3aWRnZXRzIChwbHVnaW5zKSBh bmQgaW52YWxpZGF0ZSB0aGVtIGFzIHdlbGwuCiAgICAgZnJhbWVSZWN0c0NoYW5nZWQoKTsKQEAg LTYzMiwyMSArNjM2LDIxIEBAIHZvaWQgU2Nyb2xsVmlldzo6cGFpbnQoR3JhcGhpY3NDb250ZXh0 KiBjb250ZXh0LCBjb25zdCBJbnRSZWN0JiByZWN0KQogICAgICAgICByZXR1cm47CiAKICAgICBJ bnRSZWN0IGRvY3VtZW50RGlydHlSZWN0ID0gcmVjdDsKLSAgICBkb2N1bWVudERpcnR5UmVjdC5p bnRlcnNlY3QoZnJhbWVSZWN0KCkpOwogCiAgICAgY29udGV4dC0+c2F2ZSgpOwogCiAgICAgY29u dGV4dC0+dHJhbnNsYXRlKHgoKSwgeSgpKTsKICAgICBkb2N1bWVudERpcnR5UmVjdC5tb3ZlKC14 KCksIC15KCkpOwogCi0gICAgY29udGV4dC0+dHJhbnNsYXRlKC1zY3JvbGxYKCksIC1zY3JvbGxZ KCkpOwotICAgIGRvY3VtZW50RGlydHlSZWN0Lm1vdmUoc2Nyb2xsWCgpLCBzY3JvbGxZKCkpOwot Ci0gICAgY29udGV4dC0+Y2xpcCh2aXNpYmxlQ29udGVudFJlY3QoKSk7Ci0KLSAgICBwYWludENv bnRlbnRzKGNvbnRleHQsIGRvY3VtZW50RGlydHlSZWN0KTsKKyAgICBjb250ZXh0LT50cmFuc2xh dGUoLW1fc2Nyb2xsT2Zmc2V0LndpZHRoKCksIC1tX3Njcm9sbE9mZnNldC5oZWlnaHQoKSk7Cisg ICAgZG9jdW1lbnREaXJ0eVJlY3QubW92ZShtX3Njcm9sbE9mZnNldC53aWR0aCgpLCBtX3Njcm9s bE9mZnNldC5oZWlnaHQoKSk7CiAKLSAgICBjb250ZXh0LT5yZXN0b3JlKCk7CisgICAgZG9jdW1l bnREaXJ0eVJlY3QuaW50ZXJzZWN0KGVuY2xvc2luZ0ludFJlY3QodmlzaWJsZUNvbnRlbnRSZWN0 KCkpKTsKKyAgICBpZiAoIWRvY3VtZW50RGlydHlSZWN0LmlzRW1wdHkoKSkgeworICAgICAgICBj b250ZXh0LT5jbGlwKGRvY3VtZW50RGlydHlSZWN0KTsgCisgICAgICAgIHBhaW50Q29udGVudHMo Y29udGV4dCwgZG9jdW1lbnREaXJ0eVJlY3QpOworICAgICAgICBjb250ZXh0LT5yZXN0b3JlKCk7 CisgICAgfQogCiAgICAgLy8gTm93IHBhaW50IHRoZSBzY3JvbGxiYXJzLgogICAgIGlmICghbV9z Y3JvbGxiYXJzU3VwcHJlc3NlZCAmJiAobV9ob3Jpem9udGFsU2Nyb2xsYmFyIHx8IG1fdmVydGlj YWxTY3JvbGxiYXIpKSB7CkBAIC02NTUsNiArNjU5LDEwIEBAIHZvaWQgU2Nyb2xsVmlldzo6cGFp bnQoR3JhcGhpY3NDb250ZXh0KiBjb250ZXh0LCBjb25zdCBJbnRSZWN0JiByZWN0KQogICAgICAg ICBzY3JvbGxWaWV3RGlydHlSZWN0LmludGVyc2VjdChmcmFtZVJlY3QoKSk7CiAgICAgICAgIGNv bnRleHQtPnRyYW5zbGF0ZSh4KCksIHkoKSk7CiAgICAgICAgIHNjcm9sbFZpZXdEaXJ0eVJlY3Qu bW92ZSgteCgpLCAteSgpKTsKKworICAgICAgICAvLyAyLzkvMDkgQ1NpZGhhbGwgUmVzZXQgdGhl IGNvbnRleHQgZm9yIHNjcm9sbCBkaXJ0eSByZWN0IGFzIGl0IG1pZ2h0IGJlIGRpZmZlcmVudAor ICAgICAgICBjb250ZXh0LT5jbGlwKHNjcm9sbFZpZXdEaXJ0eVJlY3QpOworCiAgICAgICAgIGlm IChtX2hvcml6b250YWxTY3JvbGxiYXIpCiAgICAgICAgICAgICBtX2hvcml6b250YWxTY3JvbGxi YXItPnBhaW50KGNvbnRleHQsIHNjcm9sbFZpZXdEaXJ0eVJlY3QpOwogICAgICAgICBpZiAobV92 ZXJ0aWNhbFNjcm9sbGJhcikK