The shortcut ALT-2 (views/darkroom/zoom fill) is broken. Using this shortcut the image starts flickering, label “working…” is shown (also flickering). Looks like an endless loop… Can be stopped by using ALT-1 or ALT-3.
Please report bugs in the bug tracker on github!
Sorry, not possible. GitHub forces me to to create an account for creating a new issue and I don’t agree with their (extremely extensive and complicated) privacy statements. That’s the reason I posted here.
I was willing to file a bug report on Github for you but…
Not able to reproduce the behaviour described by you.
No flickering, loops or any other oddities.
I just did some further investigations. It happens, if the film stripe at the bottom is decreased to its minimum. (dragging the small double arrow down as far as possible). Moving it up some pixels, the issue disappears. See the attached screenshot :
edit : it’s possible to force the issue also by having a film stripe with a large height, then pressing ALT-2 (everything is ok) and then reducing the height of the film stripe. Some pixels above the minimum height flickering starts.
The issue also depends on the width of the side panels. It can be forced by pressing ALT-2, then moving the double arrow right or left.
The issue obviously depends on the relationship of the width/height of the image area, the widths of the side panels and the height of the film stripe at the bottom.
second edit :
further investigation shows that the issue appears at the moment the slider(s) for the image area (horizontal or vertical) appear or disappear.
That’s the flickering one can observe.
What version of GTK? What, if any, kind of graphics card? Are you using X11 or Wayland?
hope this helps…
Having some more details I’ve tried to copy all the scenario’s you mention and a few you didn’t, but I am not able to reproduce, forcefully or otherwise, what you are describing.
Have you tried the newest development version? You seem to be on +584 and I initially tested with +615 and these latest tests i did with +621 both without any problems.
Here’s a better overview of my setup:
I’ll just throw this out there: the flatpak is at version 3.0, but with a newer version of gtk than @pehar uses. It supports openCL and all that good business, but requires a PPA for the latest version of flatpak itself. If you’re willing to try it out, maybe that’s a good test?
I see 4 significant differences between our systems
Here is what I tried :
Here is another way to force the issue :
Here a conclusion what happens :
There are three different states the image area can have as shown in the screenshot.
The flicker is an oscillation between this three states.
I’m wondering if the parallel processing in several threads (at least 4, possibly more) might be the reason ? If the threads running parallel are not perfectly synchonised, I can imagine the observed effects. I’m thinking about forcing my OS to use only one thread for a test, but currently I don’t know how to do so. Next weekend I’ll build a new darktable version from master, but I’m not very hopeful that this will help.
Here is another way to force the issue :
- in “settings → GUI options” set “show scrollbars for …
- …
Yep, with those steps I’m able to replicate this issue: It shows the flickering/jitterring!
BTW: Just checked stable 3.0 with the same approach: It also shows this issue.
I’ll file a bug report at the end of the day on GitHub.
I just filed a bug report:
https://github.com/darktable-org/darktable/issues/4286
EDIT: Still figuring out how pixls.us works. Changed the above link to this nice little box thingy…
Thank you for filing the bug report, so for me it was worth to invest some time to understand what happens in detail and to describe it here. I also found a way running darktable on a single cpu by using
taskset but I’m stopping further investigations now, because you confirmed the bug.
@pehar: Can you have a look at the bug report I posted for you. I’ll report back your findings if your want/need me to.
I just verified the actual behaviour with
GUI options -> miscellaneous -> show scrollbars for center view -> ligthtable and darkroom is now completely ignored. Instead of keeping the magnification and showing scrollbars, the image is now scaled down if sidebars are widened or filmstrip is made higher.One bug has been replaced by an other… , or the feature to have scrollbars is gone 
.
probably got mangled in lighttable rewrite…
@Jade_NL : I just reread the bug report once again. As far as I understand jenshannoschwalm has recognized the problem. If you find it’s indicated, I would like to see you reporting back my last findings posted in my pevious reply.
I did post that info shortly after you replied on my poke: 4th reply from the bottom one (GitHub doesn’t seem to support linking to a specific post).
We are in a holding pattern until @hannoschwalm has had time to look at it.
Nope. This already surfaced before the rewrite (can be traced all the way back to 3.0.0)
I just did a pull request tackling the disabled scrollbars.