Project

General

Profile

Bug #12387

Drawing mask / spot removal: Bug when moving shapes

Added by Stefan Klinger 3 months ago. Updated 3 days ago.

Status:
Fixed
Priority:
Medium
Assignee:
Category:
Darkroom
Target version:
Start date:
11/02/2018
Due date:
% Done:

100%

Affected Version:
git master branch
System:
other GNU/Linux
bitness:
64-bit
hardware architecture:
amd64/x86

Description

When trying to create a gradient for a drawn mask, or a shape for spot removal, I find it difficult to move around these shapes. A first click on the center line of a gradient, or on the “copy from” circle in spot removal, will make this shape jump away from the cursor.

Steps to reporduce: E.g. in darkroom module 'tone curve', select 'blend → drawn mask', then the gradient symbol, place gradient on photo, rotating gradient via the small hadles works, but when clickin on the center line it is displaced from the pointer. Drag mouse while keeping button pressed will move the gradient at its new position with different speed.

Similar for spot removal.

I have two demo videos temporarily available here [[https://depot.s5k6.net/B53pnjQAHxnTgvTw/]]. Should I upload them to the bugtracker? I'm concerned about the filesize.

Affected version:

$ git describe
release-2.5.0-743-g10a3db34c

History

#1 Updated by Pascal Obry 3 months ago

Can't reproduce. What DE are you using?

#2 Updated by Stefan Klinger 2 months ago

I need to correct myself: Above' I've said “Drag mouse while keeping button pressed will move the gradient at its new position with different speed.” but the speed is actually the same (I guess). But the shape is offset and impossible to move to the upper half of the image.

Pascal Obry wrote:

What DE are you using?

DE as in Desktop Environment ? None, if you're asking for an implementation of the desktop metaphor. It's only X11 and the FVWM window manager, so nothing fancy.

I compile from the `master` branch using a shell script like this:

cd /home/sk/source/dt/;

git clean -xdf;
git co master;
git pull;
git submodule update --recursive;

#git co my-mods;
#git rebase master;

prefix=~/.local/;

disable=(flickr libsecret kwallet unity tethering);

./build.sh -j "$(nproc)" \
           --prefix ${prefix} \
           "${disable[@]/#/--disable-}" \
           --buildtype Release

cmake --build './build' --target install -- -j "$(nproc)" 

I've just confirmed the error is still present with `master` at commit `abecd987b`:

$ git describe
release-2.5.0-767-gabecd987b

Your asking about desktop environment (I guess) made me curious, and I removed `unity` from the `disable` list. The error still persists.

Anything else I can help with?

Thanks
Stefan

#3 Updated by Pascal Obry 2 months ago

So I could guess that FVWM is probably the culprit here. Can you test with another WM?

#4 Updated by Stefan Klinger 2 months ago

Pascal Obry wrote:

So I could guess that FVWM is probably the culprit here. Can you test with another WM?

I've tested woth Openbox, and the error disappeared.

Do you have any idea where this comes from? Is this an FVWM bug (it seems to be unknown)? Darktable is the only program I use that shows pointer offset issues.

#5 Updated by Andreas Schneider 2 months ago

Pascal, I had the same issue. When you draw a shape then try to move the "copy-shape" it jumps out of the window. Running KDE Plasma here. I can't always reproduce it.

#6 Updated by Pascal Obry 2 months ago

Don't know about KDE or FVWM as I use GNOME. As an heavy user of darktable I have never seen a jump like that. So yes, I do think this is related to the WM used. Is that a bug on the WM? Probably so, but until this is tracked down by a dev using those WM it is hard to tell.

#7 Updated by Stefan Klinger 2 months ago

Ok, so I'm also going to ask the FVWM folks about this.

I've figured out that the observed bug is linked to exactly one of my FVWM settings: I have configured FVWM to capture a left mouse click/drag on a window when the Hyper modifier (aka. Windows key or logo key) is held down. In that case, the window is raised (click) or moved along with the mouse pointer (drag).

When I disable this particular binding, the jumping disappears. FVWM allows to do so during runtime using FvwmCommand(1) on the command line:

$ FvwmCommand 'mouse 1 A 4'

When I enable this binding, the jumping appears again.

$ FvwmCommand 'mouse 1 A 4 moveOrRaise'

No other of my FVWM settings had this effect, and this is reproducible. I have made a third video demonstrating this, it's temporarily available here:

https://depot.s5k6.net/B53pnjQAHxnTgvTw/03-change_mouse_binding_hi.mp4

Andreas, I do not know Plasma, but could it be configured to handle the Hyper + Button 1 combination as I have described? If so, does this trigger the effect?

#8 Updated by Stefan Klinger 2 months ago

I do not know if that's related to this bug, but FVWM complains about darktable in the following way:

[fvwm][GetWindowSizeHints]: <<WARNING>> reason: 1: The hints have been ignored because the window's current size would have become invalid.  The new hints will become active when the window generates the next ConfigureRequest.

[fvwm][GetWindowSizeHints]: <<WARNING>> The application window (id 0x1200003)
  "darktable" has broken size hints (inconsistent with current size).
    fvwm is ignoring those hints.    hint override = 0, flags = 310
  min_width = 1172, min_height = 274, max_width = 0, max_height = 0
  width_inc = 0, height_inc = 0
  min_aspect = 0/0, max_aspect = 0/0
  base_width = 0, base_height = 0
  win_gravity = 1

    If you are having a problem with the application, send a bug report
    with this message included to the application owner.
    There is no need to notify fvwm-workers@fvwm.org.

#9 Updated by Stefan Klinger 2 months ago

I have used `git bisect` to track down where this bug was introduced:

$ git bisect good
92c1733369600cb034852676124026479aa69c83 is the first bad commit
commit 92c1733369600cb034852676124026479aa69c83
Author: edgardoh <edgardo.hoszowski@gmail.com>
Date:   Sat Sep 29 07:31:06 2018 -0300

    fix cross position

:040000 040000 b76bf5ce67082ae9bf7772a447921dc05ca07c32 6e0e84d8e2ef961f8cf6ae7aaf1f541f1c8d879b M      src

This commit does a lot of things involving the terms "mouse", "event" and "mask". But I certainly do not understand how this code works.

Playing with FVWM and trying to find the bug on their side, I assume that keyboard modifier `mod4`, commonly bound to the Windows/Logo key, is involved.

Discussion is on the mailing list.

#10 Updated by Edgardo Hoszowski 2 months ago

I just entered PR bug 12387 #1812, please test it.
https://github.com/darktable-org/darktable/pull/1812

#11 Updated by Stefan Klinger 2 months ago

I'm sorry to say that the bug is not fixed.

I've verified the bug's effect wich commit e30c70f3d as well as with f36458080.

I've also cloned your git repo, and verified the bug exists with commit e98d935ad.

#12 Updated by Edgardo Hoszowski 2 months ago

I cannot duplicate on my environment, and by just looking at the code I got nothing. What I can do is to add a PR with some debug messages for you to run, so maybe we get more info.
Let me know if you are OK with this.

#13 Updated by Edgardo Hoszowski 2 months ago

Just entered Bug 12387 #1824
https://github.com/darktable-org/darktable/pull/1824

Let's continue this conversation on the actual PR, I don't mind having private messages but there may be people interested on this.

#14 Updated by Richard Askwith 2 months ago

For what is worth, I am having the same problem.

My operating system is a Linux distro; 'Elementary OS'. I am running Darktable version 2.4.2. It was installed using the Elementary OS AppCentre.

Let me know if I can give you any other info.

#15 Updated by Stefan Klinger 2 months ago

Elementary OS? So I assume that you do not use the FVWM window manager, but rather Gala. That would be the first evidence that this bug is not isolated to FVWM. Could you verify this?

#16 Updated by Richard Askwith 2 months ago

Yes, that is true. I am using the stock release of Elementary OS Juno based upon Ubuntu 18.04. No tweaks other than receiving standard updates.

#17 Updated by Andreas Schneider 2 months ago

I had that issue some days ago with KDE Plasma, however I can't reproduce it as reliably as Stefan.

#18 Updated by nostromo eiljeen 20 days ago

Pascal Obry wrote:

So I could guess that FVWM is probably the culprit here. Can you test with another WM?

I am running Ubuntu 18.04.1 LTS and my WM is fluxbox.
For me the problem occured only after an upgrade from DT2.4 to DT2.6, and I can reproduce it with any drawn mask shape.
But for me there is also a "jump" when trying to rotate a gradient mask, which rotates the gradient.
I tried with a clean config (removed my ~/.config/darktable folder), as I thought it might be some setting problem after the upgrade, but the behaviour is unchanged.

PS: the video-links are all dead links, so I cannot watch the videos that describe the problem, but from what I read, it is exactly the problem I am facing.

Best regards, nostromo

#19 Updated by Stefan Klinger 20 days ago

nostromo eiljeen wrote:

I am running Ubuntu 18.04.1 LTS and my WM is fluxbox.

I'm kind of "glad", in the nicest possible way, to hear that I'm not alone here.

For me the problem occured only after an upgrade from DT2.4 to DT2.6,

I think the bug was introduced in commit 92c17333, well after 2.4, see #12387#note-8.

and I can reproduce it with any drawn mask shape. But for me there is also a "jump" when trying to rotate a gradient mask, which rotates the gradient.

I observe that too. I'm pretty sure all these effects are linked to a bug in the translation of mouse pointer coordinates in an event handler responsible for dragging, shared by all kinds of shapes, and IMHO when rotating the gradient it's least obvious what's happening, so I did not mention it — sorry. Edit: My memories betray me, after reading my initial report again, I think that the effect on rotating the gradient is new.

PS: the video-links are all dead links, so I cannot watch the videos that describe the problem, but from what I read, it is exactly the problem I am facing.

I've re-uploaded them for another month. I'm hesitant to upload huge files to this bugtracker without explicit permission. Someone's paying for the storage, and I'd find that abusive.

As described in #12387#note-7, my window manager FVWM captures mouse-button-1 events when the Hyper modifier (aka. Windows key or logo key) is held down, and the bug disappears when I remove that binding (which is not a feasible workaround). Do you have a similar binding with fluxbox? And can you test what happens when you change that?

I'd be happy to provide any further info required to fix this. Currently I cannot really use shapes.

#20 Updated by Richard Askwith 18 days ago

Glad to see that this issue is still alive! I would like to be able to reliably use Darktable's outstanding masking features.

Since I last posted, I have switched from Elementary OS to Ubuntu 18.04.1 LTS and I am still experiencing all of the problems described above. I do have a few additional observations.

  • Sometimes when I try to create a "drawn mask", the mask will draw in a completely different location from where my cursor is.
  • Sometimes I experience the same jumping problem when rotating a gradient mask.
  • Not all of my images have this behaviour. Sometimes the masks work perfectly.
  • Sometimes discarding the "history stack" will correct the problems, however it means redoing all of my edits.

#21 Updated by nostromo eiljeen 17 days ago

Stefan Klinger wrote:
I'm kind of "glad", in the nicest possible way, to hear that I'm not alone here.

"We are not alone", as Agent Fox Mulder would put it :)
I added a new user to my system, so no per-user settings would cause such a behaviour.
I logged in to the Xorg desktop using GNOME, and could not reproduce the problem.
But logging in using fluxbox with default settings, and I had the problem again.
So to me it looks like it has something to do with more uncommon WMs, like FVWM or fluxbox.

[...]

I've re-uploaded them for another month. I'm hesitant to upload huge files to this bugtracker without explicit permission. Someone's paying for the storage, and I'd find that abusive.

Thanks, the videos show exactly the problems I am facing. And yes, I would also prefer external links to bigger media files.

[...] mouse-button-1 events [...] Hyper modifier [...] Do you have a similar binding with fluxbox? And can you test what happens when you change that?

Hmm... fluxbox has several settings for that, but as far as I know some of them are default, like M-LMB to move, and M-RMB to resize a window, "M" being the AltGr-modifier in my case.

Best regards, nostromo

#23 Updated by nostromo eiljeen 5 days ago

Edgardo Hoszowski wrote:

I've entered PR #1998 for this
https://github.com/darktable-org/darktable/pull/1998

I applied the patches, recompiled darktable and can happily report, that this fixes the problem for me.
Thanks so much!

Best regards, nostromo

#24 Updated by Stefan Klinger 4 days ago

I've run the following tests on this (release-2.6.0rc2-49-g87cbaccbd), and the problem seems fixed:

Spot removal {
  circle {create, moved {source, target}},
  ellipse {created, moved {source, target}, rotated, resized, changed width},
  path {created, moved, resized, nodes {moved, rotated, changed transition}},
  circle deleted,
  ellipse deleted,
  path deleted
}

exposure > blend > drawn mask {
  brush {created, moved, nodes {moved, rotated},
  circle {created, moved, resized},
  ellipse {created, moved, resized, changed transition, changed width, rotated},
  gradient {created, created, moved, rotated},
  gradient deleted,
  circle deleted,
  path deleted,
  ellipse deleted
}

Thank you very much Edgardo!

#25 Updated by Pascal Obry 3 days ago

  • Target version set to 2.6.1
  • Status changed from New to Fixed
  • Assignee set to Pascal Obry
  • Priority changed from Low to Medium
  • % Done changed from 0 to 100

Also available in: Atom PDF