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 171465 - Magnifier source bounds issues in horizontal mode
Magnifier source bounds issues in horizontal mode
Status: RESOLVED FIXED
Product: gnome-mag
Classification: Deprecated
Component: magnifier-utility
unspecified
Other Linux
: High major
: ---
Assigned To: bill.haneman
bill.haneman
AP2
Depends on:
Blocks:
 
 
Reported: 2005-03-24 09:08 UTC by Dragan Sarbut
Modified: 2005-12-16 16:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test program used (6.64 KB, text/plain)
2005-03-24 09:12 UTC, Dragan Sarbut
  Details
new test program (3.66 KB, text/plain)
2005-06-23 06:55 UTC, Dragan Sarbut
  Details
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. (2.36 KB, patch)
2005-11-26 17:43 UTC, Carlos Eduardo Rodrigues Diógenes
accepted-commit_now Details | Review

Description Dragan Sarbut 2005-03-24 09:08:42 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.
Comment 1 Dragan Sarbut 2005-03-24 09:12:20 UTC
Created attachment 39190 [details]
test program used
Comment 2 bill.haneman 2005-03-24 11:55:40 UTC
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.
Comment 3 Dragan Sarbut 2005-03-24 13:56:59 UTC
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.
Comment 4 Dragan Sarbut 2005-06-23 06:55:48 UTC
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.
Comment 5 Dragan Sarbut 2005-06-23 06:59:55 UTC
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
Comment 6 bill.haneman 2005-06-23 09:14:45 UTC
this is a known issue, yes.  The problem seems to be that the source bounds are
getting incorrectly reset for some input conditions.
Comment 7 bill.haneman 2005-06-23 09:16:01 UTC
Priority is not AP1 (it's been triaged before).
Comment 8 Carlos Eduardo Rodrigues Diógenes 2005-10-18 13:38:03 UTC
I don't understand the discussion about AP1 (or is API?). Can anyone explain
this better or point to where it was triaged?
Comment 9 bill.haneman 2005-10-18 13:51:02 UTC
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.
Comment 10 bill.haneman 2005-10-18 13:52:23 UTC
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.
Comment 11 Dragan Sarbut 2005-10-18 14:00:27 UTC
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.
Comment 12 bill.haneman 2005-10-18 14:21:14 UTC
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).
Comment 13 Carlos Eduardo Rodrigues Diógenes 2005-10-18 18:23:08 UTC
where can be find the informations what is AP1, AP2, etc??? I search the site,
but don't find anything.
Comment 14 Carlos Eduardo Rodrigues Diógenes 2005-11-26 17:43:43 UTC
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.
Comment 15 Carlos Eduardo Rodrigues Diógenes 2005-12-16 00:26:27 UTC
anyone saw the attachment that I send? Any feedback about it?
Comment 16 bill.haneman 2005-12-16 15:57:22 UTC
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!
Comment 17 bill.haneman 2005-12-16 16:09:05 UTC
fix committed to CVS HEAD.