Ah, I had missed that you did a recalc at full image, rather than screen, resolution when toggling. On lower powered machines (GPUs with less memory) a large image might need tiling, making a recalc significantly slower. Because this happens in the display thread, the whole UI locks up while this recalc is happening. Yes, I realise that snapshots does this as well (see my earlier remarks about a redesign needed) but at least those are lower resolution and partial images. I wonder if it would be possible to limit most of your changes to develop.c (and specifically dt_dev_get_viewport_params/ dt_dev_get_zoom_scale and the like) so that all the zooming/panning/displaying can function unchanged, just using the results stored in preview2.pipe->backbuf without triggering further recalcs. Then the one-of âfinalâ recalculation of the image at high resolution could happen in that pipe as normal, in the background.
Limiting special cases and code duplications makes an eventual redesign easier / less daunting.
Running your code, I get
(darktable:26746): Gtk-WARNING **: 09:25:18.151: ../../../gtk/gtkoverlay.c:678: invalid child property id 1 for "pass-through" of type 'GParamBoolean' in 'GtkOverlay'
This may be wayland related.
I also get strange behavior when pinning in a zoomed state and then trying to zoom out the pinned image or changing images. May be intentional.
And I get crashes. Maybe related to memory use and trying to recalc large images.
Sure, I know that well. The current implementation should be considered a proof of concept. If there is no objection I can prepare a PR (after 5.4 is released, that is) and then we can iterate on the details.
I might also be a bug that would explain why I cannot see tooltips on the buttons, I need to look at it more closely.
There will never be an objection to submitting a PR (unless it is AI slop). There will also never be a guarantee that it will be accepted. It all depends on suitability, stability and code quality. Personally, I prefer discussions around easily accessible code, so anything thatâs beyond suggestions/requests/daydreaming (which would be FR issues) and that has working code (for some value of âworkingâ) can be submitted as a draft PR. And either further developed or replaced by a final. I prefer that to having long discussions here that inform the eventual design but are not captured in GitHub and therefore most likely wonât be available for future reference without requiring a significant amount of investigation. Iâm aware thatâs not a generally held opinion and that many would want to have as much community input as possible, but as soon as the issues become technical, having too much noise that doesnât take into account the possible can just lead to disengagement from those who have better things to do with their time. Having at least the barrier of requiring a github account is imho not too much to ask.
Tooltips get disabled when the widget is not in the focused window and can also be toggle with shift-t. But yes, passthrough or GDK_ENTER/LEAVE_NOTIFY_MASK can also have an impact.
As promised, now that 5.4 has been released this became a PR:
@dterrahe I followed your advice and reimplemented things so that the 2nd window uses its own pixelpipe. I hope that I interpreted your comments correctly because it was a bit of a bloodbath
Latest video demo for the curious (there are a bunch of random composite/watermarks in the photos because I was testing the interaction of the change with those):
The technical discussion can now continue in the PR.
I still welcome folks to use this thread to discuss the feature and how it can be further improved.
