After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 618397 - 20Hz polling when magnifier is enabled
20Hz polling when magnifier is enabled
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: magnifier
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2010-05-11 19:39 UTC by Colin Walters
Modified: 2021-07-05 14:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Colin Walters 2010-05-11 19:39:13 UTC
So one thing that came up earlier in the magnifier review is that it has a 50Hz timeout to check the cursor position.  I actually changed this just before I committed the patch to only be active if the magnifier was on, but that's still not very good.

I think we should be able to track the cursor position by watching for motion events on the Composite window, but not entirely sure.
Comment 1 Owen Taylor 2010-05-11 19:55:54 UTC
(In reply to comment #0)
> So one thing that came up earlier in the magnifier review is that it has a 50Hz
> timeout to check the cursor position.  I actually changed this just before I
> committed the patch to only be active if the magnifier was on, but that's still
> not very good.
> 
> I think we should be able to track the cursor position by watching for motion
> events on the Composite window, but not entirely sure.

No, you can't. Events are received only when the pointer is over the *input shape* of a window. (or, in other words, if the composite overlay window was getting the events, nothing else would)
Comment 2 Colin Walters 2010-05-11 20:27:56 UTC
Hm, well we should scope out a way to make this happen.  A new addition to XFixes?
Comment 3 Magdalen Berns (irc magpie) 2014-03-05 06:14:25 UTC
Is this actually still a problem?
Comment 4 Joseph Scheuhammer 2014-03-05 15:18:19 UTC
(In reply to comment #3)
> Is this actually still a problem?

Less so than before.

The polling is now handled by the PointerWatch object; hence, the magnifier is no longer directly polling (as it was when this bug was filed).

Even so, it would be better if there was a callback-on-movement technique.  But, then, it's not an issue with the magnifier nor even gnome-shell.  As Colin noted in comment 2, a callback solution might have been implemented in X.  Since the switch to Wayland, perhaps that is the locus of the work.

Maybe keep this bug around until/if/when there is something that reacts to mouse movement?  Not sure.
Comment 5 Magdalen Berns (irc magpie) 2014-03-10 23:08:40 UTC
(In reply to comment #0)
> So one thing that came up earlier in the magnifier review is that it has a 50Hz
> timeout to check the cursor position. 

Line 21 at link https://git.gnome.org/browse/gnome-shell/tree/js/ui/magnifier.js#n21

> I actually changed this just before I
> committed the patch to only be active if the magnifier was on, but that's still
> not very good.

Commit link https://git.gnome.org/browse/gnome-shell/commit/js/ui/magnifier.js?id=dc424280a10b43b3855ff3ee247685d30e415a84
Comment 6 Magdalen Berns (irc magpie) 2014-03-10 23:40:42 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Is this actually still a problem?
> 
> Less so than before.

Thanks for the reply and information.
> 
> The polling is now handled by the PointerWatch object; hence, the magnifier is
> no longer directly polling (as it was when this bug was filed).
> 
> Even so, it would be better if there was a callback-on-movement technique. 
> But, then, it's not an issue with the magnifier nor even gnome-shell.  As Colin
> noted in comment 2, a callback solution might have been implemented in X. 
> Since the switch to Wayland, perhaps that is the locus of the work.

This has happened already? I thought it was wip until the next release until
you said, I'll have to have a look!

> Maybe keep this bug around until/if/when there is something that reacts to
> mouse movement?  Not sure.

I have actually seen this issue! I thought it was a memory leak or something
causing performance degradation but had not properly considered that mouse
polling was related to that issue at all until just now - oops. I will take a
look at the state of the problem in wayland once I see what the craic is (there
have been some bugfixes sinc I last checked that may or may not be relevant
too), If not:

I don't know what the rationale was for creating the pointerWatcher but i
vaguely suspect (if one exists then) the solution is to be found with C. I
think mouse event changes are being written in the mutter-wayland repository,
but I have not paid attention too much lately. It does seem likely that this
has become more possible now that wayland is closer (here?) so I will post back
if anything obvious jumps out at me when I check this.
Comment 7 GNOME Infrastructure Team 2021-07-05 14:21:26 UTC
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, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.