GNOME Bugzilla – Bug 684246
An actor should get a crossing event when it moves underneath the pointer
Last modified: 2021-06-10 11:31:07 UTC
When animating actors (x, anchor-x, scale, etc.) such that the pointer stays still but the actor moves to under the pointer, or leaves from under the pointer, enter/leave events are not generated. Next enter/leave event is generated only the next time the pointer is moved. This makes it fairly difficult to make reliably working hover effects. ------- Comment #1 From pippin@gimp.org 2008-11-20 11:38:57 [reply] ------- To get enter/leave events when actors and not the cursor moves, we need to hook reactive actors moving into the function that generates the enter/leave events. Just hooking into stage redraw would work but probably impact performance more than making it happen when the allocation of reactive actors change. ------- Comment #2 From Tommi Komulainen 2008-11-20 12:01:26 [reply] ------- And by allocation you of course mean transformation? And not only the actor itself, but any of its ancestors. ------- Comment #3 From pippin@gimp.org 2009-01-15 16:22:19 [reply] ------- I think I mean the allocation, some of the layout machinery is still gray magic to me. The issue of missed enter/leave events will also occur when a pointer grabs are released (presumable the actor under the cursor when the grab is released should receive an enter event). ------- Comment #4 From Matthew Allum 2009-01-20 14:38:06 [reply] ------- Probably not that hard to implement but would mean a pick for every frame rendered so will have a very likely notice-able performance impact. Unsure if that could be avoided beyond having a global toggle on the feature. ------- Comment #5 From Tommi Komulainen 2009-01-20 15:38:58 [reply] ------- (In reply to comment #4) > Probably not that hard to implement but would mean a pick for every frame > rendered so will have a very likely notice-able performance impact. Unsure if > that could be avoided beyond having a global toggle on the feature. Using motion events frequency should reduce the impact somewhat. ------- Comment #6 From Havoc Pennington 2009-05-01 22:41:14 [reply] ------- bug 1576 plus (bug 949 or bug 1526) could probably lead to a fix here. perhaps some of the picking ideas in bug 1526 about tracking bounding box and which actors color outside the lines are helpful too. Another thought is to just have a manual repick and run it on end of animations. ------- Comment #7 From Havoc Pennington 2009-05-01 22:44:05 [reply] ------- Repick on any size allocate of stage and end of any animation would probably catch 95% of cases, without slowing down transform-based animations. ------- Comment #8 From Emmanuele Bassi 2009-11-24 18:04:28 [reply] ------- the pick-before-paint branch contains a fix for this bug. a pick is performed using the location of the pointer before processing all the events; all events in the queue will then use the actor under the pointer as the source. I cannot see any performance difference between master and this branch: I still get 60fps on my 945 and my 965. ------- in reality, picking before each paint introduces a performance penalty. in the future, we want to move away from a "paint in pick mode" and towards a client-side hit detection using the actor geometry and paint volume, so that we can use a separate thread for event processing and dispatch; this would allow to always be able to compute the hierarchy underneath the current position of the pointer for each frame.
another side effect of this kind of functionality would be that Clutter emits a crossing event in case the actor underneath a pointer gets removed/destroyed. I think this bug can only be solved without the performance impact of painting the scene once again if we switch away from the picking approach, and use client-side hit detection; this will, sadly, require an API break.
*** Bug 755162 has been marked as a duplicate of this bug. ***
Created attachment 311568 [details] [review] device-manager: Allow updating devices for a specific stage Instead of updating all devices, we may have a specific stage that we wish to update the devices for. https://bugzilla.gnome.org/show_bug.cgi?id=684246 https://bugzilla.gnome.org/show_bug.cgi?id=755162
Created attachment 311569 [details] [review] stage: Update the input devices on redraw We want to know the actor beneath the pointer even if the scene is being animated and the pointer does not change its position. This is something we've been exploring for years; the last time I checked, it was in the run-up to the 1.0 release of Clutter, and on underpowered devices, like the original Atom netbooks, the performance loss was measured in 20-30%. We could still achieve 60fps, but there was a definite cost. These days, the bandwidth at our disposal, as well as the drivers, are a bit better, so doing a readback is not so terrible. Doing a "get the actor beneath the pointer" operation is also limited to redraws that changed the layout, instead of every single frame; this should limit the amount of picking on static scenes. https://bugzilla.gnome.org/show_bug.cgi?id=684246 https://bugzilla.gnome.org/show_bug.cgi?id=755162
Why would we be doing a readback at all? Shouldn't we be going through the journal in nearly all cases?
In theory, yes; but if something flushed the journal in response to a relayout, then we wouldn't. Not that I expect it to be the usual case, mind.
The patches aren't enough: we have a bunch of optimizations in place, and the result is that we discard the updates queued during the paint. The devices are updated, and the events are processed, but there is no visible update of the scene, so this needs further work.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of clutter, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a ticket at https://gitlab.gnome.org/GNOME/clutter/-/issues/ Thank you for your understanding and your help.