GNOME Bugzilla – Bug 70236
Drag-and-drop excruciatingly painful over dsl X connection
Last modified: 2017-10-16 14:21:46 UTC
I reported the ff to bugzilla.ximian.org, but they claim it's a gtk bug. I know nothing about gtk, but am submitting it here. --------- Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: When I drag a mail message into another folder while running evolution over an X connection, the animation showing the message icon moving from one place to a new folder is incredibly slow. How slow? I'm gaining weight because I have time to go to the kitchen and get some cookies. Steps to reproduce the problem: 1. Drag message to another folder while running evo over DSL-based X connection. (ssh in my case). Actual Results: Painfully slow animation. Expected Results: Fast animation, or no animation. How often does this happen? Evory time I forget to move mail with some technique other than drag-and-drop. ------- Additional Comments From Jeff Stedfast 2002-01-30 13:40 ------- You'd do better re-submitting this to the Gtk developers I'd think. There is nothing special we do with d&d in Evolution.
Hmmm, it is a lot worse than I would expect. Some of the slowness is unavoidable -- latency is the problem over DSL and DND inherently involves a lot of round trips. But it seems that the drag isn't "catching up" to the pointer. It looks like the problem is that I was assuming that GDK_POINTER_MOTION_HINT_MASK worked with gdk_pointer_grab() while in fact it seems to do nothing.So, we'll have to do catch-up in some other way. I would advise, if possible, running IMAP over the DSL connection rather than evolution; GTK+ (except for DND) isn't bad, but you'll certainly get snappier interactive feel with IMAP.
Moving non-critical and hard-to-fix bugs to 2.0.2
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
Have some code for this, but it isn't going to make 2.2.0.
In exactly one week, this bug report will celebrate its first birthday.
Just a baby, really. E.g., bug 1165 is almost 4 years old. Attaching the code I wrote earlier so it doens't get lost.
Created attachment 15033 [details] [review] patch with various speedups
Created attachment 15034 [details] Asynchronous X hackery, C flie
Created attachment 15035 [details] Asynchronous X hackery, H file
All, of this and much much more is now in CVS. I'm not going to paste the ChangeLog here as I normally would since it is 80+ lines. Performance over a slow link is way better than it was (10-100x times better, in fact) but still far from great. There are still three remaining things I want to do, which are a little - Use a better method of catching up motion events - Make the assumption that if the toplevel frame stays the same, the window with WM_STATE stays the same. - Use Xrender AA-cursors to draw the drag icon when possible. If you combine all three of these, then you can actually have *0* round trips per motion when DND'ing from an application to itself. (It was around 10 before the change I put in, is currently 3). The Xrender cursor approach will also greatly improve drag startup time, which is still the bigger problem, eliminate exposes underneath and of course, allows 90% opaque drag icons. The changes I have put in are 2.4-target material, since they are too major to go into a stable release.
Created attachment 47510 [details] [review] use RGBA cursors for dnd instead of windows
The patch extends the support for DND icons and cursors in three ways: 1) Use icon themes when determining the images for the drag cursors. The icon names are "dnd-cursor-ask", "dnd-cursor-copy", "dnd-cursor-move", "dnd-cursor-link", "dnd-cursor-none". 2) Use an RGBA cursor instead of cursor+window if the server supports RGBA cursors of the necessary size, and if the application doesn't use a widget or pixmap as source for the icon. The reduces the roundtrips during a drag operation and allows for translucent icons. 3) If an RGBA cursor can not be used, but the server supports RGBA visuals, use a window with an RGBA visual instead of a shaped window for the icon. Part 3) is untested, and the patch may still have some issues with the handling of hot spots and the offset between cursor and icon.
As discussed with Owen, 3) is probably not a good idea, since the presence of an alpha visual does not guarantee that the window will actually be translucent (if no compositing manager runs), and adding shape+alpha visual will likely lead to ugly cut off fades in many cases. Applications which want to use large, translucent dnd icons can still do so, by providing the icon in the form of a RGBA window.
Committed the RGBA cursor patch now. I'll leave this open for the remaining roundtrips (are there any ?)
I wonder if the original bug is still considered as present? If not, and if there are no more known problems, we could just close this bug.
Eric: Is this still an issue or can this be closed nowadays?
Let's close this, and let Eric reopen it if desired, or some other user create a new one if they see the same problem today. As well as the commits here, a lot else will have changed since then, so it's possible things are very different.