dtgtk/button.c: _button_draw() called on every "cursor moved" event #11836
Labels
Comments
|
Maybe we can check here for "mouse over other widget" in some way and only redraw in such a case? |
|
hmm... I don't reproduce for the mouse move outside the histogram bounding box... Maybe there's something more specific to do in order to reproduce ? |
|
Or this may be due to the DE which send too many events? |
|
This is the first few seconds after starting dt in lighttable view with Strictly nothing done other than moving cursor. Note that many of the tooltips belong to popups (color profile, overlays) that need to be clicked to be displayed, so this means that GUI elements that are not even visible are redrawn anyway. |
|
Here I redid an experiment with timings making sure the cursor was only over blank space in the sidebar: |
|
oh... seems that you repeat all the same sequence, certainly on each move, as you say... And just for the testing, if I hide all the panels, I get no msg, whatever the focused window, and whatever the mouse movements... I'm really not sure what happens here... |
|
just to be sure we are doing the same thing, I've put the |
yes. |
|
Also, if you go in darkroom after launching |
|
Again, we have already seen that, this may well be a DE issue. So first let's see what you are using. I bet @AlicVB is using GNOME or KDE where the multiple events issue has never been reported. |
|
I'm on KDE. |
|
I'm on XFCE... |
|
Belatedly, I can't replicate this on Gnome. I do see the (known) weirdness that as the cursor moves into the histogram, there are a couple button draw events for each button and the histogram is redrawn a couple times. I think this is because GTK is using a transition to fade in the buttons. The GTK buttons are awkward, due to using GtkOverlay, which isn't really meant for this work, drawing the buttons redraws the histogram (this probably could be fixed by double buffering). If you want to see something even worse, check out the tethering view, where (last I tested), every mouse movement in the center view redraws the entire center view!
I'll try to test later today, am not set up for this now. I did use KDE for a while, recently, and noticed a bunch of things are just-a-bit-off with the bauhaus widgets. Also, maybe #8765 is related to this? |
|
Although pretty to to comment here, i did a lot of testing otherwise but disdn't observe this issue, Fedor 36 gnome, both xorg and wayland for testing. |
|
This issue did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue. |
|
This issue was closed because it has been inactive for 300 days since being marked as stale. Please check if the newest release or nightly build has it fixed. Please, create a new issue if the issue is not fixed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Trying to investigate the reason why the histogram is polluting the stdout with messages saying it recomputed on any cursor move (even outside of the histogram bounding box), I had the idea of adding
fprintf(stdout, "button drawn\n");in the_button_draw()method ofsrc/dtgtk/button.c.It turns out that any cursor move seems to redraw all of the GUI buttons all the time, which seems to be the cause to redraw the parent histogram too. But we are talking 2 to 15 ms for each redraw on Xeon only for the histogram, so that's a lot of CPU cycles lost at the scale of the whole window.
Not sure what to do next.
The text was updated successfully, but these errors were encountered: