Created attachment 213533 [details]
Graphical artifacts, occured when quickly panning from upper-right to lower-left

Here's a simpler testcase that shows the garbage (tearing?) more clearly -- image is just a simple brush swipe across the canvas.

Occurs at any zoom level, in or outside of the image area.

*** Bug 675529 has been marked as a duplicate of this bug. ***

The bug is still in Gimp 2.8 final version. Here are two videos showing this annoying behaviour

http://www.youtube.com/watch?v=gpARpvEDH0Y

http://www.youtube.com/watch?v=QNsoPXulxgY

Hey, 
 
I'm experiencing the same issue. The issue did not occur on GIMP-2.6.

Hardware/Software info:

OS: Windows 7 Home Premium / 6.1.7601 SP1 Build 7601
RAM 8 GM / 5.60 Available/Free Memory 
Video: AMD Radeon HD 7950 / Version 12.3

This bug is still present in GIMP 2.8.0

Win7 Pro x64, 8GB RAM

I used the Windows installer by Jernej Simončič, straight from the GIMP Downloads page
http://www.gimp.org/downloads/


Plenty of documentation of this bug, here's somebody else who did a YouTube video
http://www.youtube.com/watch?v=YUofvMmDpC8&t=0m23s

These guys were talking about it in RC1
http://www.gimpusers.com/forums/gimp-developer/14265-slow-artifact-prone-redraw-when-panning-in-2-8-0-rc1


I don't see how this is still marked as "UNCONFIRMED".  This is the kind of bug that turns users away FAST!  Several forums had people talking about downgrading to older versions because of this bug.

Only someone with sufficient bugtracker permissions (e.g. a GIMP developer) can officially change the status off of "Unconfirmed".  Bugtracker status codes have official meaning - see this page for details:
https://bugzilla.gnome.org/page.cgi?id=fields.html#status

I didn't mean to imply that I don't understand the Bugtracker system.  I realize that only a developer can change the status of the bug.

What I'm saying is that for such a serious UI bug, I don't understand how a developer hasn't made that change already.  It's been reported here for over a month, since RC1, and reproduced by many users in a wide variety of forums.

Perhaps a dev will get see the renewed discussion and make the change.  In that case, I want to express my clear appreciation for all of the work that's gone into 2.8.  This bug was a real heartbreaker only 30 seconds into my fresh install of software I've been looking forward to for more than two years.

Confirmed, if it makes you feel better. This will however change
nothing about the bug at all, unless you bring us a windows developer
who is able to fix it.

*** Bug 676640 has been marked as a duplicate of this bug. ***

Ok but...now what? Until a super-cool windows programmer comes and fixes it we have to stuck at 2.6? Where the hell "testing" ended up??

Sorry, I don't want to be mean but...before releasing it U didn't notice that on win7 64bit it simply doesn't work? o.0*

That's what I cannot understand...I know that "shit happens"...I'm a programmer too but...this is quite huge actually...waiting other 2 years to get to the 3.0 version to have it working? o.0

If you're a programmer too, fix it. 

Testing happened. There were development releases. You never tested them I guess.

It's also not a show stopper for many. I use gimp on win7 occasionally myself. Never saw this bug... I just dont pan/zoom that much I guess. Huge? I woudnt say so. An issue sure... Oh, and just waiting until 3.0 is NOT going to fix anything. This is something that works on Linux and not on Windows. It needs a windows developer, probably one well versed in both windows and probaly cairo that is used to draw the canvas.

Sigh... Just to be clear - I do not see how this construes a release blocker. It's a visual non-crashing self-clearing minor defect... Yes, it could use a fix. But definetly not one worth the foot stamping and drama.

This is *precisely* what we did, because we have literally zero-to-one
windows developers. We have millions of users on windows, but it seems
that either none of them are developers, or they don't care.

So unless this changes, gimp will be broken on windows. and it will
become more and more broken, worst case we have to drop support for it.

Sorry I forgot bugs were splitted in the other bug report and I was referring my comment to the whole thing.

I think thou that here we're talking only about this graphic issues but we should wide up and speak about THE graphic issue that is annoying this beautiful version...it's not only panning which is affected but there are other graphic glitches that happen here and there.

But yet I do understand You when You talk about the "windows developer thing" but I do not understand why 2.6 was working (and since 2.8 is an improvement it should still be working) and why U say that this piece of art is something that works on tux and not win...it always worked on win...

btw I can live with graphs issues, my greater issue is the wacom not correctly working on 2.8 but it's another bug. Won't talk 'bout here.

I was goin' to write "I would help if I could but, sadly I can't (for many reasons which I won't explain here, it's quite useless)." but then before posting I read Your posts...tell me how could I help...*maybe* I will find a way to...

GIMP depends on many things that are not gimp itself. Cairo, in this case is the most likely culprit, but we cant even be sure of that, because nobody can debug on windows. Support for windows comes through these libraries. Sometimes library is changed and tested on linux and works fine, but since nobody builds on windows, bugs on windows get back to developers when ever there is a release and then they come from people unable to debug or fix them. That means issues on windows have horrid fix lag. 

Your tablet issue btw, is known. Has been known for a while, but since gimp relies on an obsolete version of GTK on a very poorly supported platform to begin with, if an when it gets fixed is a total unknown. There is a workaround. Put your pen to tablet before you start gimp (start it using the tablet).

As to how you can help... even if you cant code, being able to build and debug on windows is a BIG thing. If you are able to find the causes to bugs like this even with the prcision of a library they are very likely to be fixed. That's the main issue with GIMP on windows -  nobody building and debugging.

Tell me what I should do to compile and I'll try to do something to help.
The problem is that I do not have time (seriously...i'm not kiddin' sadly) but I do use gimp a lot, even at work...so trying to help is the least I can do.

I will arrange a virtual machine, tell me what to download and what to do next and I'll try my best.

I can maybe convince another person to work at it and I've already posted in g+ that GIMP needs windows develops...maybe somebody will answer the call.

http://wiki.gimp.org/index.php/Hacking:Building/Windows

this is a start, but like all developent on windows, its patchy and incomplete. Btw, gimp release builds for windows are cross-compled on linux... Help on windows is very much appreciated, but it's a lot of hard work getting started.

Ok I'll see what I can do.
I've already contacted my friend and he said he'll take a look too.

How to contact You or anybody else in case of needs?

http://www.gimp.org/irc.html and the gimp-developer mailing list.

k

Thanks Phssthpok, and help here is greatly appreciated :)

YV, hope I'll be able to help! ;)



ps


wacom workaround isn't working for me =.[

I know this isn't much help, but when you suggest cairo as the main culprit, I'm thinking it's not necessarily cairo itself, but could be GIMP's manner of implementing it that creates the problem.  If it was a bug in the library itself it should affect all applications equally (like GTK+ bug #549839), but other apps that use cairo, like Inkscape, do not show the bug.  (Then again, Inkscape also has a different version of cairo, and official Windows developers...)

Guys sorry...honestly at this point I do not know what we're dealing with...could plz somebody update me so maybe I'll be able to knowledgeably (does this word exists? XD) speak about it? =)

My newe screencast video:
Gimp_2.8.0_Graphic_Bug.mp4 


http://www.youtube.com/watch?v=CpE_WHlcFjs

My new screencast video:
Gimp_2.8.0_Graphic_Bug.mp4

http://www.youtube.com/watch?v=CpE_WHlcFjs&feature=youtu.be


I am Gimp trainer on several scools but sorry I cant't work with 2.8!

Currently I write my new German book "GIMP 2.8 Praxisbuch" and I will describe this bug.

The Link to the last book (GIMP 2.6 Praxisbuch":
http://www.amazon.de/Gimp-2-6-Praxisbuch-%C3%9Cbungen-Video-Tutorials/dp/3826655176/ref=sr_1_2?s=books&ie=UTF8&qid=1338890257&sr=1-2

So let me understand...

You use gimp, which is free.
U write books and earn moneys (guess even when U teach it)...aaaaaaaand...U complain about the bug, *even* reporting it in your book!?!?

Ok...am I the only one seeing something's wrong here??

U earn money and complain, it's still ok;
U will be putting it in your book without helping fixing it???? R u kiddin?? This is NOT ok...

At least I did complain but I will try to help...equal...I am asshole but I'm tryin' to redeem myself! =) Maybe I'll not being able to but I will try...I'm not going to say everywhere to everyone "hey, GIMP is buggy!"..

Wtf...ok, there is an issue, they have explained it's not their fault, and U still "punishing" the thing? 

Mah....IMO it's wrong...

The new book will be ready at the end of this year. And I help many new Gimp unsers to understand this wonderful image manipulation program. I hope this nerved bug is fixed to this time (2.8.1?). You understand: I can't only describe the good features of Gimp, I have to describe also critical facts. But I report this bug in bugzilla because I wish to help for improving Gimp 2.8. I'm not a developer, I'm only a photographer and a normal user. Sorry for my incorrect English...

Your english is perfectly understable, don't worry.

I didn't want to sound rude...aand put under this way sounds quite ok...

Bug #675546 appears to be a duplicate of this one.

By the way, it may be worth noting the bug DOES NOT occur when you scroll by mousewheel (not matter how fast) - but it occurs quite easily when using the spacebar for panning.

Phssthpok, have you made any progress on identifying the cause of this?

*** Bug 680390 has been marked as a duplicate of this bug. ***

Oh god, too much off-topic talk here. Please, stick to the issue. Create new issues for other issues. And do your off-topic somewhere else. And oh boy, that shameless advertising, contributing nothing.
Enough of that, to add something useful:

I can confirm the issue on Win7 x64, Gimp 2.8.0.
When panning horizontally or vertically only, the issue is less visible then when scrolling diagonally in both directions.
What I’d suspect after playing with it a bit is that it’s the painting mechanism. The updated, panned image is started to be painted, but does not finish before another panning-event occurs, resulting in a cancelled full-paint and repaint in the new location. This will prevent lagging behind the panning-action but lead to such tearing obviously.

That this would be a show-stopper, I can not understand. Without having experienced both, I’d say I prefer more uptodate partly drawn image over lagging behind.

Is this not an issue on *nix?


Contrary to what has been said, I can reproduce this issue on Inkscape on my Win7 x64 as well, Inkscape 0.48.
Trying with a simple, black rectangle:
Although it is not as visible (not visible at all) when panning within the visible area, when you move the rectangle partly out of the window (past the edge) and back in, it is even more severe than in Gimp as Inkscape seems to update (repaint) the new position but not the old, if you move fast enough, resulting in a black trail from the edge to the new position. Yes, you can get it across the entire screen.
Additionally, the issue is very visible when (proportionally) resizing the rectangle. Even when resizing very slowly, the issue is very visible.

When putting the image I tested with in Gimp into Inkscape and panning, I can not see issues panning the image. Again, only in the edges and when resizing.

In contrary to Inkscape, gimp seems to use a rasterising approach (repaint each x pixelgrid columns).

http://git.gnome.org/browse/gtk+/commit/?id=fe67f04a16bf5edeae6a925051ed1a811638619d is suspected to be the cause for this.

Bug triaging results: 

After confirming this with the author in the aforementioned commit,this is a GTK+ bug. Bugsquad, please change the product according to this.

Addition: the bug still occurs in the current 2.8.2. build on Windows.

Reverting product field from GTK+ back to GIMP, as the GIMP project is the only one still using GTK+2 and we need to find these bugs.

*** Bug 682741 has been marked as a duplicate of this bug. ***

*** Bug 691234 has been marked as a duplicate of this bug. ***

I just upgraded from 2.6.x to 2.8.2 and hit this bug.
So I can confirm the bug is still alive and kicking in the current latest version, and it makes gimp UNUSABLE.

My technical details:

OS: Windows 7 64bit
Graphics card: ATI Mobility Radeon HD 3650
RAM: 4GB

Please consider this a major issue, I'd be happy to sacrifice some of the new features if you isolate the cause and make it a preference switch like disable Cairo rendering. Still there are a lot other features in 2.8 that I would enjoy using without having to downgrade to 2.6 :(

GIMP is far from "unusable" with this bug on the lam.  As noted above, the glitchy behavior + slowdown only seems to occur if you're panning via Spacebar, and only past a certain minimum speed (e.g. if a mouseover event occurs from within the current redraw event).  Scrolling via mousewheel does not reproduce the behavior -- a completely usable workaround, at least if you don't need to scroll beyond the image borders.

(In reply to comment #41)
> Scrolling via mousewheel does not reproduce
> the behavior -- a completely usable workaround, at least if you don't need to
> scroll beyond the image borders.

Yes, it does reproduce it. (2.8.4 from the website) I'm downloading the latest source from Git and will take a look at the code as soon as I get the time. This may not make GIMP unusable, but it's a definite turn-off for a lot of Windows users.

Given GIMP's userbase, it's surprising that you guys don't have any active windows developers.

BTW, has anyone ruled out that this is caused by libcairo? Cairo can be replaced on an installed GIMP without the need to recompile.

It's not cairo or gimp - a while ago, I confirmed it was definitely the GTK+ commit mentioned above (http://git.gnome.org/browse/gtk+/commit/?id=fe67f04a16bf5edeae6a925051ed1a811638619d). Forgot to report that here.

Actually, reverting that commit fixes this issue, but reintroduces the scrolling artifacts that were present in 2.6 if a window was above the image window. Those artifacts don't go away on their own, so I decided the new scrolling artifacts might be better.

Notably, the 2.6 artifacts don't appear on windows 8, but they do happen on windows XP. I assume that windows 7 and Vista would behave more like windows 8 in that respect. So, an argument could be made for simply reverting that commit.

I did take a look at the code and try to fix this for good, but documentation on the related windows API is scarce, and I couldn't wrap my head around how this code is supposed to work.

Maybe one of our millions of Windows users got an idea. We could post a news item on www.gimp.org about it.

Partha has reported that he hasn't got such reports for his builds (I'm not sure if users of his builds report to him directly, though). 

As this is caused by a GTK+ commit, I really wonder how that build could not exhibit the problem...

(In reply to comment #46)
> Partha has reported that he hasn't got such reports for his builds

I just downloaded Partha's 32bit build (Gimp-2.8.4-32bit.exe) and installed it on an old Windows XP machine.

Sadly it shows the same problem as the GIMP standard build.

We've got a similar report on the mailing lists, too.

So it is due to the commit mentioned in comment #44. Maybe someone has an idea how that could be changed?

I looked at comment #44 and the commit mentioned in there:
https://git.gnome.org/browse/gtk+/commit/?id=fe67f04a16bf5edeae6a925051ed1a811638619d

Code to scroll before the change (in pseudo-code):
  Call Windows function BitBlt

Code to scroll after the change (in pseudo-code):
  if GDK_IS_WINDOW_IMPL_WIN32:
    Call Windows function ScrollDC
  else
    Call Windows function BitBlt

This change was made, because on Win32 systems, the BitBlt function copied garbage, if the source to be copied was obscured by another window.

The ScrollDC function does work, but during its operation shows the undesired artefacts.

Essentially it looks like a timing problem. Certainly this is called in an event loop during scrolling, and the poor machine can't keep up with all the events. It's more visible on 32 bit systems, but as comment #33 confirms, also happens on 64 bit systems. If less events were fired, surely the artefacts would be reduced.

Anyway, just my 5 cents of wisdom.

I am really confused now.

Calling BitBlt was replaced by calling ScrollDC to fix this problem:
"When scrolling a window partially obscured by another window, artifacts of the obsuring window where being blitted into the newly scrolled position."

Is there a bug for that?

I installed 2.6.12 (XP 32 bit), opened a picture, put the toolbox window on top of it and started scrolling. No problem, no artefacts.

So which problem was solved? Why solve an (alleged) problem by creating a huge problem elsewhere? I am in favour of putting the BitBlt call back. ScrollDC is known NOT to provide smooth scrolling (just google it to see).

Another thought. On Windows, scrolling a partially covered window does not bring this window to the foreground. In other words, if the toolbox is on top, scrolling the underlying image leaves the toolbox on top.

Not so in Linux. There the windows is brought forward, then the scrolling begins.

So if there really were a problem with scrolling a partially obscured window, then the right way to fix it would be to bring the window forward first, causing it to repaint, then to start scrolling.

And finally: In 2.8.4 we have a single window interface, which many people will use. So it's less likely that the main window will be covered by floating windows. This as well reduces the occurrence of the (alleged) problem that triggered this change.

None of the people on this bug's CC list will have an answer to this
question. I guess only Dieter Verfaillie and/or Alexander Larsson
can answer that.

Jorg, you are aware that the commit we are talking about is in GTK+ not GIMP?

Hi Michael, I have e-mailed Dieter Verfaillie and Alexander Larsson asking them to comment here. As I am new to GIMP (I've worked on Thunderbird and Musescore before), I'm not aware of anything ;-) However, http://www.gtk.org/ tells me, that GTK+ stands for GIMP Toolkit, so to the layman that's close enough to GIMP. In the commit mentioned in comment #44, they mention that the fix was made to address an issue in GIMP. As stated above, I don't think it's the right fix. All other software built on GTK+ will suffer the same slow behaviour of the Windows ScrollDC call, as far as I can see, for no good reason.

Let's hope Dieter and Alexander comment on this.

There was clearly a bug before, and reverting this change reintroduces it as per comment #44. And, note that this is a very lowlevel generic issue, so any behaviour on the high level like "raise some toplevel" window is not really useful here. This affects ever scroll operation in every gtk app, some where raising the window is clearly wrong.

However, it seems the fix is not quite enough as it introduces other issues. We need to fix that by actually understanding the exact problem that causes the tearing and *fix* that, not by random workarounds. 

I believe the issue is somehow related to _gdk_win32_window_queue_translation() which is supposed to handle the case where we're moving bits of the window around and the window may have areas that needs update. We *should* always be calling this before the ScrollDC call, but maybe this goes wrong somehow, or ScrollDC interacts some unexpected way with the Update Region. Unfortunately I don't really have much time to work on the win32 stuff, so someone else will need to debug this.

I would recommend looking at the wine implementation of ScrollDC:
http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winex11.drv/scroll.c
it may give hints on the details of how ScrollDC works.

Thank you for your comments.

I wasn't suggesting to raise some windows from the low-level code, I was merely stating that on Linux the windows is raised before the scrolling begins. IMHO this option exists here, too, of course the logic for raising the window would have to go elsewhere.

I didn't dig through the code, but the ScrollDC will call the Win32 function directly, will it not? I'm not sure what GDI_CALL (BitBlt, ..., does, ie. whether this is a wrapper for Win32 BitBlt or some own implementation.

As for Wine: This emulates/implements the Win32 function ScrollDC. Are you suggesting to replace Win32 by GIMP's own implementation? Or are you saying that the Wine implementation sheds some light on how ScrollDC is implemented by Microsoft? Why would that understanding help?

IMHO ScrollDC is just too slow to be called in a rapidly firing event loop, and doesn't catch up, therefore the tearing.

I'm inclined to offer my help here, with some guidance of course, but I can't reproduce the original bug (refer comment #44) on my system with 2.6.

Sorry in advance if any of these questions/remarks are silly ;-)

Both BitBlt and ScrollDC are win32 calls, the only difference is that ScrollDC uses the update region too, there should be no performance difference (at least not in the not overlapped case) at all. Calling ScrollDC rapidly should not cause tearing, independently on how slow it is, i don't understand how you could think that.

About the Wine reference, its a great "doc" for the MS APIs which are otherwise very poorly documented. They spend a lot of time testing apps making sure they handle all the weird cases, so its a reliable source too.

If the only difference between before and now is calling ScrollDC and not BitBlt, how do you explain the tearing? The call interface to ScrollDC is very simple, so there is nothing that can be changed in the call, well, lprcClip could be passed not NULL to see whether that makes a difference.

You are saying that "there should be no performance difference" and that "calling ScrollDC rapidly should not cause tearing". Both statements use conditional tense "should".

I agree. But it DOES cause tearing. And since we have no control over the Windows call, we can either
1) implement a replacement or
2) go back to using BitBlt and make sure that this call works in the context where a previously obscured area is blitted or
3) raise the window being scrolled like on Linux, then BitBlt should then work.

Or perhaps you think ScrollDC is called in the wrong context and a preceding call to _gdk_win32_window_queue_translation() - as you stated above - is missing.

Sorry once again for any silly question.

Could you give some direction on how to proceed. And also, on how to reproduce the original problem of creating artefacts when scrolling an partially obscured window.

Sorry, before you tear your hair out over the silly comments, read the code again. The change was not to replace BitBlt by ScrollDC, but by ScrollDC followed by InvalidateRgn (ugly code, executing functions in the else if). The latter will cause the now exposed region to repaint.

Surely two calls, one triggering a repaint (via an event), are much slower than a simple blit and can cause all sorts of strange effects.

Oh boy. I meant to say: **I** read (past tense) the code again. No offence intended. Sorry.

The interface to ScrollDC is not a simple call, it interacts in very complex ways with the win32 update region, the gdk invalid region, the gdk/win32 events and expose machinery, etc. Somewhere this goes wrong, we need to figure out where.

None of the 1-3 is what we should do. We should figure out what *actually* goes wrong, rather than guessing wildly about "its slow" and then fix the underlying issue. Now, I don't know *exactly* what goes wrong. But guessing on this bug will not bring me closer. Only debugging, testing and reading code will do that. 

If anyone is interested in this I'd recommend trying to create a minimal testcase for the bug and use that to see exactly what the conditions are that cause the problem. Then when you can reproduce this, look at exactly how the win32 update region is affected in thew various step, and how the gdk invalid region is affected. Somewhere these two go out of sync, likely the translation of one of the regions is applied twice. Or perhaps the update area is incorrectly cleared without being handled somewhere.

I'd like to capture some information received from Dieter Verfaillie (quote):
[The original problem] was a generic issue with all GTK+ apps, but one could
reproduce it (at least on XP) by for example dragging gimp's toolbox window over gimp's canvas window and then scroll the canvas window. See:
https://live.gnome.org/GTK%2B/Win32/test-gtk-2-24-win32?action=AttachFile&do=get&target=ScrollingArtifacts.png
(end quote)

(Silly) Questions:
- this should be exposed in GIMP 2.6.12? I can't reproduce it on XP 32 bit.
- Could that be a graphics driver problem, where Windows (BitBlt) calls on the driver to move an area of pixels, potentially previously obscured? Or do drivers not have a concept of windows?
- In the original problem: How does one restore the correct canvas? Minimise/Maximise? Cause it to repaint by moving another window over it?

===

Re. Alexander's comments:
From what you say I read, that the problem is not in the ScrollDC, which to my untrained eye has a very simple interface, but in the following repaint caused by InvalidateRgn? Here is the code:

if (!ScrollDC (hdc, xdest - xsrc, ydest - ysrc, &scrollRect, NULL, updateRgn, NULL))
  WIN32_GDI_FAILED ("ScrollDC");
else if (!InvalidateRgn (src->handle, updateRgn, FALSE))
  WIN32_GDI_FAILED ("InvalidateRgn");

It is the repaint that interacts with the rest of the system, and there tearing can happen, if for example some transformation is not correct.

It seems like ScrollDC behaves really weird on windows 7. If you scroll a region some areas are not bitblt:ed but instead invalidated. This happens not only if the window is overlapped by some other window, but in completely normal scrolling operations. The way this is handled on gtk+ atm is that these will be drawn in the next update, so eventually we'll get this right, but we'll be lagging the redraw one frame causing the tearing.

Since these kinds of updates are now kind of important i've change gdk to handle them in the same drawing cycle, which removes the tearing:
https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=4f2725630679966dd1148644105fd5592ac95ec8
https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=ea66a8a580ad496dc375ce6afeb2ee29f585a7fb
https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=692a0e5906c5da7f85c16c9d6cbb0d3ed8b4a576

Somehow it seems that this thread may have drifted from the original reported bug.

The recent flurry of posts regarding ScrollDC seem to now be described as "tearing".  And the method for Reproducing is now a floating window dragged across the canvas window.

Are we sure this is still the same fundamental issue, about artifacts while panning the canvas?

Video links from mi_emilio_es still show the originally reported issue from last year
http://www.youtube.com/watch?v=gpARpvEDH0Y

... which seems to be different from the screenshot from Jorg K
https://live.gnome.org/GTK%2B/Win32/test-gtk-2-24-win32?action=AttachFile&do=get&target=ScrollingArtifacts.png

Just wanted to make sure we are all still on the same (improperly displayed) page.  Particularly important since the "tearing" issue commit from Alexander was the basis for marking this Bug as "Fixed".

Did that solve the scrolling issue?

Yes, it did. Having said this, I have to take Alexander's word for it, since I haven't tested it.

This bug is about the tearing/shredding when scrolling the canvas, which was introduced while fixing another bug (artefacts when scrolling partially covered canvas window).

The fix addresses the problem reported in the bug, whilst not undoing the fix for the previous bug. 

The screenshot in my comment related to the previous bug and was just posted here, so we all know what the previous bug was, since it's not easy to reproduce.

Executive summary: All good, this bug fixed, previous bug remains fixed.

Fantastic news.
Thanks for the fix Alex, And thanks for the summary Jorg.

I know it's almost taboo to ask, but...
With this commit, when could we expect an updated version of GIMP to be distributed reflecting this fix?

Yes, I realize that if we build from source, we could have it now.
I mean, when might the GIMP sourceforge dl page reflect an updated build?
http://sourceforge.net/projects/gimp-win/

Thanks again, this one was really annoying.

New release will be available when the respective volunteers find the time.

*** Bug 674928 has been marked as a duplicate of this bug. ***

I'd like to understand whether the bug fix was included in 2.8.6.

GNU Image Manipulation Program version 2.8.6
git-describe: Unknown, shouldn't happen

using GEGL version 0.2.0 (compiled against version 0.2.0)
using GLib version 2.36.1 (compiled against version 2.36.1)
using GdkPixbuf version 2.28.0 (compiled against version 2.28.0)
using GTK+ version 2.24.18 (compiled against version 2.24.18)
using Pango version 1.34.0 (compiled against version 1.34.0)
using Fontconfig version 2.10.92 (compiled against version 2.10.92)
using Cairo version 1.10.2 (compiled against version 1.10.2)
(Type any character to close this window)

So this is compiled against GTK+ 2.24.18 which should include Alexander's fix.
https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=9f16fc1b003c6e4c5095fe277f67be6bf8c8ffee

However, the problem is still present on my Windows 7, 64bit installation.

FWIW, I had this bug and updating to 2.8.6 fixed it. I'm also using 64 bit GIMP on Windows 7.

OK, I am now comparing 2.8.4 with 2.8.6 in greater detail.

When scrolling in 2.8.4, the refresh is lagging behind in many small areas, which leads to a "shredded" impression of the image, just as if it had been run through a document shredder. When scrolling using the scroll bars, many small horizontal or vertical stripes are visible, when scrolling via "hold down the space bar and move the mouse", many weird and wonderful areas appear.

In 2.8.6 the situation is much better, yet not perfect. When scrolling using the scroll bars, there are now bigger blocks lagging behind in their redraw, instead of many small stripes. When using the "hold down the space bar and move the mouse" method, the shredding effect has gone away, yet, larger areas now lag behind in the redraw.

So sorry about my hasty comment, I had forgotten, how bad 2.8.4 really was. The fix is a huge improvement, however, it leaves a little bit to be desired.

Perhaps the person who raised the bug can comment and tell us, whether he considers the problem fixed.

If these artifacts go away by themselves, the bug is fixed,
if they stay around, it's not.

Are they temporary or do they stick around?

Temporary. Refresh is lagging behind. When it catches up, all is well.