https://bugzilla.gnome.org/show_bug.cgi?id=763298
Carlos Garnacho <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
Attachment #323362|none |reviewed
status| |
--- Comment #1 from Carlos Garnacho <[email protected]> ---
Comment on attachment 323362
--> https://bugzilla.gnome.org/attachment.cgi?id=323362
Don't reset the drag status if not needed
Thanks for the patch, I'm however not sure that's the right approach, that
partly breaks the contract of GTK_DEST_DEFAULT_MOTION (which is issuing
gdk_drag_status calls automatically).
I've been looking these last days into GtkNotebook tab DnD and also run into
this, what's really happening here is that we possibly issue multiple
gdk_drag_status() calls (with different drag actions) when processing the
GDK_DRAG_MOTION event. This burst of action changes actually trigger a
renegotiation, with signals emitted to both the drag source and destination.
The destination side queues quickly get flooded by the many .set_action
requests done and .action events received.
I think the solution is to coalesce these calls, so only one happens per
GDK_DRAG_MOTION event. Because of the bottom to top approach in
gtk_drag_find_widget(), we will be consistently sending the same status as long
as the pointer sits in the same area, so we will be triggering a lot less noise
at the protocol level.
I'm attaching a couple of patches with the fix I came up with.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
wayland-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs
