GNOME Bugzilla – Bug 171465
Magnifier source bounds issues in horizontal mode
Last modified: 2005-12-16 16:09:05 UTC
Using gnome-mag from HEAD and a modified control-client test program. 1. start gnome-mag in a termial by typing "magnifier -mv" 2. use control client and : - first set the zoomer placement : "./control-client T" - then resize the zoom-region: "./control-client b" Notice that the magnifier shows only black and gray. Note: This only happens for some values. You can find the values for which the bug reproduces in the control-client.c file that I will attach.
Created attachment 39190 [details] test program used
the zoom region _does_ resize properly. You may be suggesting that the source display size is not resizing properly, but I believe that it is.
Bill, Please do the test. Do you think that the values from the attachement are wrong? This is exactly what gnopernicus is doing when changing the zoomer-placement. I'm not sure what's going wrong in gnome-mag but appearantly something is since this is reproductible with control-client.
Created attachment 48196 [details] new test program To test: 1.in a xterm start the magnifier in vertical split-screen mode and foloing the mouse ("magnifier -mv") 2. use the "control-client" program attached and first set the target bounds (3.) and then resize the viewport (4.): 3. ./control-client T 4. ./control-client b Notice that the mouse pointer is still in the middle of the magnifier which is good, but you cannot see anything in the magnifier which is bad.
I'm not sure that this is the correct title for the bug, but since the resize_region function is called that's the place to start. Setting priority AP1 since this is almost as important as vertical split-screen magnification. All the tests were done on a 1024/768 resolution
this is a known issue, yes. The problem seems to be that the source bounds are getting incorrectly reset for some input conditions.
Priority is not AP1 (it's been triaged before).
I don't understand the discussion about AP1 (or is API?). Can anyone explain this better or point to where it was triaged?
Carlos: please see the 'Status Whiteboard' field. This field is where the accessibility team puts its assessment of a bug's impact on key accessibility use cases.
bug does not result in data loss, does not entirely prevent the user from using the desktop or system, and can be worked around. Currently horizontal split-screen magnification can be used if the parameters in gnopernicus are set beforehand, then both gnopernicus and the magnifier service are exited and restarted.
I don't think that a gnopernicu restart is needed for split-screen magnification. I think is enough to turn off the magnifier from gnopernicus and then turn it back on.
Thanks Dragan. That sounds nicer. It seems to be working OK for me at the moment, with the restart. If you haven't tested lately already, try horizontal splitscreen and let me know if it works OK after turning off the magnifier and turning it back on (maybe you were confirming that it does, in your comment #11, but I was not totally sure).
where can be find the informations what is AP1, AP2, etc??? I search the site, but don't find anything.
Created attachment 55255 [details] [review] Add logic in zoom_region_update to copy for pixmap and zoom_region_paint_pixmap to resolve the problem. Running the mag with gnopernicus presented a strange behave, but the service alone works well.
anyone saw the attachment that I send? Any feedback about it?
Comment on attachment 55255 [details] [review] Add logic in zoom_region_update to copy for pixmap and zoom_region_paint_pixmap to resolve the problem. Running the mag with gnopernicus presented a strange behave, but the service alone works well. looks good Carlos, thanks!
fix committed to CVS HEAD.