Drag display jumps back to prior location on mouse release

[stefanor]

Reported in Debian: https://bugs.debian.org/925278

Package: xdot
Version: 1.0-1
Severity: normal
Tags: upstream

on exceptionally complex graphs that are displayed on extremely high resolution
screens, the refresh rate of xdot can be as low as two (2) SECONDS per frame.
not two frames per second, two SECONDS per frame.

this provides a unique means of identifying an otherwise obscure bug.
action is as follows:

• load up ridiculously large graph on 3000x1800 (or greater) full-screen LCD
• press and hold mouse
• move mouse (to activate "display drag")
• whilst STILL MOVING the mouse, LET GO of the button.

what will happen is that the display will jump BACK to a FORMER (last updated)
position, as opposed to leaving the display where the cursor is PRESENTLY
located.

this is understandable extremely annoying behaviour, as it requires an
additional two (or greater) seconds of holding the mouse absolutely still,
waiting for an otherwise unnecessary display-update in order that the last
known prior location become the present location, such that, on release of
the mouse, the bug will not result in the display jumping to an undesirable
location.

it is also understandable that given that most people do not view ridiculously
complex graphs on ridiculously high resolution LCDs, that the bug may never
have been encountered before.

[jrfonseca]

I don't have huge graphs/screens readily available. So I tried to repro this by introducing an artificial delay:

diff --git a/xdot/ui/window.py b/xdot/ui/window.py
index fa17078..85a40da 100644
--- a/xdot/ui/window.py
+++ b/xdot/ui/window.py
@@ -187,6 +187,9 @@ class DotWidget(Gtk.DrawingArea):
         cr.translate(-x, -y)
         self.graph.draw(cr, highlight_items=self.highlight, bounding=bounding)
 
+        import time
+        time.sleep(1)
+
     def on_draw(self, widget, cr):
         rect = self.get_allocation()
         Gtk.render_background(self.get_style_context(), cr, 0, 0,

and followed the steps above (letting go of the button while still moving) but I couldn't see the issue. AFAICT, the final position is precisely the one when the mouse button was released.

I wonder if for such high resolution displays we should give the option to user lower (e.g, half) resolution.

[bredelings]

I may have the same problem, although I do not have a huge screen. I also use Debian, and I noticed a month or two ago that the xdot GUI had gotten incredibly slow. So, I wonder if this is a result of a change in the cairo or gi packages on Debian.

What I mean by "slow" is that, for example, mousing over the "+" button has about a 2 second delay before the focus highlight for that button shows up. I also have to press the button for like 5 seconds in order for button presses to register. For the last few years, this has not been the case.

I did try xdot on a smaller graph, and the slowdown did not occur. It is also the case that if I resize the window for the large graph to be very small, then the GUI updates much faster. In fact the speed for the large graph seems proportional to the size of the window! As I resize the window to be larger and larger, each resize starts taking multiple seconds.

Do you have any idea what might be causing this slowdown?

I have attached an example of slow and fast graphs below.

graphs.tar.gz

[bredelings]

It also seems to be the case that, for the large/slow graph, the GUI speeds up as I zoom in, and the number of nodes in the viewport goes down. Maybe this would indicate that somehow the entire scene is getting redrawn in order to shade a button?