Version: CVS (using KDE Devel) Installed from: Compiled sources I'm seeing paint errors on scroll in Ideal mode again. I'm using F4 to jump from compiler error to error. I have the bottom messages tab up in overlap mode. If the F4 jump makes the screen scroll about 2/3 of the way, I'm getting gray artifacts from the Messages window in the editor window. Using Kate
Yeah, I thought I had fixed this, but it would seem it broke again or it wasn't completely fixed... I'm thinking about turning off kate's optimised scroll drawing... :(
The bug looks to be in kate. The overlay has damaged part of the Kate windows. Kate records this damage. But now you scroll Kate before it paints. Kate needs to adjust the recorded damage areas for the scroll. It doesn't look like Kate is doing this.
The bug is probably in Kate's scroll window function. Kdevelop should not be able to impact this.
Trust me, I know where this bug is. If it was easy to fix, it would be already.
hamish, you seen that too again ? me really thought would be solved, hadn't it here since your last fixes :/ btw., jon, you use kdevelop + kdelibs CVS head, or ?
I am on kdevelop and kdelibs CVS head. I've earn learned to whack my entire install tree and rebuild a new one after each update. I just checked in /proc/pid/map and I definitely have the CVS version loaded.
Yes, I have seen it too. I don't know what's happened, yet.
This seems to have gotten better recently. But I just hit one I hadn't seen before. Normally you see this bug when the ideal window down at the bottom has been scrolled up. I just saw it the other way, the window scrolled down exposing a grey area at the top that never got repainted.
CVS commit by rodda: Removing an incomplete hack and replacing it with a proper technique with very little performance loss. This hack tried to check that another repaint event was not issued around the time that a scroll was triggered, as we would have to repaint the translated area because the image on-screen had already been scrolled. It was successful, but only partially (the bug was only noticed less often in kdevelop). This solution tracks which requests come from 3rd party applications, and triggers an update of the whole view rather than trying to QWidget::scroll() when that is the case. It fixes it and is elegant :) This also contains a slight change to the buffer highlighting tracking for kio-accessed files, to make it more correct (there may have been a bug here or not, we only got one unconfirmed report). CCMAIL:72562-done@bugs.kde.org M +9 -5 katedocument.cpp 1.681.2.1 M +11 -9 kateview.cpp 1.333.2.1 M +4 -4 kateview.h 1.159.2.1 M +0 -23 kateviewhelpers.cpp 1.5.2.1 M +13 -49 kateviewinternal.cpp 1.276.2.1 M +3 -6 kateviewinternal.h 1.95.2.1
Just got this again but via a new path. I had a menu open that was obscuring part of the kate area. I then used the mouse scroll wheel to scroll. Part of the menu ended up in the kate area as a paint bug. I am synced to CVS at Feb 15 AM.
There is a trick to this. Drop the menu down, make sure it overlaps some of the Kate area. Then move the mouse from being over the menu so that it is over the Kate area. Don't click on anything. Now spin the scrollwheel up. That will cause a paint error of the menu into the Kate area.
CVS commit by villat: Fixing a paint error when a scrollwheel occures while a menu is opened. CCMAIL: 72562-done@bugs.kde.org M +5 -0 kateviewinternal.cpp 1.294 --- kdelibs/kate/part/kateviewinternal.cpp #1.293:1.294 @@ -2944,4 +2944,9 @@ void KateViewInternal::wheelEvent(QWheel } else { scrollViewLines(-((e->delta() / 120) * QApplication::wheelScrollLines())); + if (e->delta() > 0) { + // maybe a menu was opened -> we shall erase it + update(); + leftBorder->update(); + } }