GNOME Bugzilla – Bug 167705
magnifier crosswires initially have tendency to leave trails
Last modified: 2005-05-24 17:32:25 UTC
Distribution/Version: JDS Rel3 B28 Using gnome-2.6 and gnopernicus 0.10 With magnifier options set up as default (split-screen and crosswires on). - Start up gnopernicus. - Go to startup mode. - Disable all options and press "Ok". - Go back to startup mode and enable magnifier. - Press "Ok". Notice that the user moves the mouse, the crosswires do not refresh properly - there is a trail of crosswires that soon consumes the screen. This stops as soon as an application, such as gedit or gcalctool is activated. Also notice that if the user presses "Apply" intead of "Ok", then the "Startup Mode" dialogue remains (as expected). The same problem occurs with the crosswires but stops as soon as the user moves the mouse pointer outside the "Startup Mode" dialogue.
it would be interesting to see what the magnifier is being sent (command-wise) during this sequence, as opposed to normal operation. Very odd.
Bill, nothing changed in gnopenricus in the srcore<->gnome-mag communication. If nothing is changed in gnome-mag either I suspect this could be a build problem, maybe an X server bug. I will attach a patch that prints what is sent to the magnifier, maybe there is something goin wrong. You are right, this is strange.
Created attachment 37642 [details] [review] test patch This patch prints the xml string that contains the magnifier settings. Please apply it and send us the output.
I cannot reproduce this on build 26. I will install build 28 and check again.
I managed to reproduce this bug with build 29. 1. This dows not happen all the time. 2. Here's what happens when the bug is reproduced: - when moving the cursor slowly so the magnified region remains the same, the trails appear. - as soon as the magnifier has to update what it's showing, the crosshair trails dissapear. This is a problem for half and full screen magnification because the region that the magnifier is showing is not as often updated as when the magnifier has a smaller size. Maybe this region should be updated with every ROI change that gnopernicus is sending. This is not a gnopernicus bug so I'm transferring it to gnome-mag for evaluation.
If gnopernicus is sending new ROI calls that don't actually change the ROI (i.e. they are redundant), then it is a gnopernicus bug.
Bill this isn't about changing the ROI, the problem is that gnome-mag is not updating the crosshair position after the cursor position changes.
I didn't say something right. Gnome-mag is changing the position of the crosshair, but it doesn't refresh the background untill the mouse is moved out of that area.
Dragan: this doesn't happen in standalone mode, so it has to do with the commands the magnifier is being sent. You imply in comment #5 that gnopernicus may be sending multiple setROI commands that have the same coordinates.
I just checked that in gnopernicus : We are _not_ sending ROI change commands unless the magnified region changes. So I was change my statements in: "without changing the ROI from gnopernicus, gnome-mag doesen't refresh what it's showing. As soon as the new ROI is sent to gnome-mag, the trails dissapear."
Notice that this bug is only reported present when gnopernicus itself has focus, otherwise John indicates that it does not occur. Dragan, can you confirm this? It does not appear to happen in standalone mode.
Bill, what do you think gnopernicus does wrong and the stand-alone tester doesn't?
Bill: I just reproduced the bug using control-client. Do not start gnome-mag by using "magnifier -mv". I started gnome-mag with control-client by using command line "./control-client c". As I stated above, this does not happen every time, but I reproduced it 2 out of 5 times.
Thanks Dragan. I'll investigate.
Hi Bill, I have a little bit more info. Attached is the control-client test program that I used. It's the standard one, I just commented a line; I tested by running "control-client c". When I reproduced the bug I noticed that the cursor doesn't appear at the start, just the crosswire which leaves the trails. To reproduce this open a xterm, put it on the left part of the screen and strech it to cover almost all of the left side of the screen. Now run "control-client -c" (if it doesn't reproduce the first time, do a "pkill mag" and try again) As I said above, the cursor did not appear _but_ as soon as the cursor reaches the edge of the terminal window, it will change shape and the magnifier cursor will apear and this bug dissapears. So, even a cursor-change makes the magnifier to work ok, not only a ROI change. Hope this helps. Tests were done in JDS 3 b29.
Created attachment 38500 [details] test-program Here is the used control-client program