GNOME Bugzilla – Bug 773359
Strokes painting outside the image window are joined internally
Last modified: 2018-05-24 17:08:10 UTC
Since commit 3a44989a4528a if a continuous stroke is partially gone outside the image window, it is drawn as if the exit/entry points were joined by a straight line. See https://bugzilla.gnome.org/show_bug.cgi?id=771444#c34 and the attached image: https://bugzilla.gnome.org/attachment.cgi?id=338265 [It is a bug not present in version 2.8.18 but likely in the release to come for which there is not yet the version field]
As the description is now much more generic than in the original comment - this is still limited to the specific case there, right? Or does it happen always now?
It happens regardless of the core pointer tool. The point is with current gimp-2.8 when the core pointer has a different tool the stroke is interrupted as soon as it reaches the edge of a dockable or of the window, so it is already not possible to paint going outside the image window.
And this is due to the patch? I don't recall this happening to me when I was still using Windows. If this is due to the patch, we will have to revert, this is too much of a regression - or fix this issue then.
I agree. Painting over the window border and back in the same stroke must work. We should probably simply prevent the tool change instead of bailing out. Maybe it's time to use a proper API for input devices, has gtk3 switched away from wintab in the meantime? I can't imagine such shit happens with a real API provided by windows itself.
(In reply to Michael Schumacher from comment #3) > And this is due to the patch? I don't recall this happening to me when I was > still using Windows. > Did you see the video attached to bug 767467? Do you recall that happening to you when you were still using Windows? That predates the patch and so it is not due to the patch > If this is due to the patch, we will have to revert, this is too much of a > regression - or fix this issue then. I noticed it and reported it because it is not in a released GIMP version and you're in time to revert it or fix it. As a regression it is a change between two wrong behaviours. With the core pointer tool != stylus tool, you can paint behind a dock overlapping the canvas vs you can't (it stops the stroke and leaves GIMP undo in an inconsistent state etc) With the core pointer tool == stylus tool, there are no wrong pressure artifacts painting behind a dock but exiting and entering are joined. Anyway, without the patch, leaving and entering the canvas while painting, showed wrong pressure artifacts (as shown in the video), so you can name it a regression, but it did not break something that used to work flawlessy. (In reply to Michael Natterer from comment #4) > I agree. Painting over the window border and back in the same stroke > must work. We should probably simply prevent the tool change instead of > bailing out. > That's what https://bugzilla.gnome.org/attachment.cgi?id=335684 does and I preferred the one I pushed because testing on Windows I noticed only the behaviour painting behind the dock window because at the time I thought it was the only way GIMP received these wrong motion events. Anyway in the next days I have little time for GIMP. So tell me if you want me to revert the commit. For whatever else you don't need my blessing
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/998.