GNOME Bugzilla – Bug 375782
The performance of orca full screen magnification is not good.
Last modified: 2008-07-22 19:33:11 UTC
Please describe the problem: This is an performance bug for orca full screen mag with virtual frame buffer. Steps to reproduce: 1. Configure the virtual frame buffer on a machine. 2. Invoke orca and enable the magnifier. 3. Set the source screen to :0.1, target screen to :0.0, zoom place to the maximum of screen resolution. 4. Move mouse cursor around the magnified screen, click the launch menu button and select one menu item in All Applications->Accessories->Test Editor. Actual results: The performance of orca full screen mag is not good, we can see lags while moving the mouse cursor, while gnopernicus full screen mag is better that orca does. Expected results: The performance of orca full screen should not be worse than gnopernicus full screen mag since they are based on gnome-mag. Does this happen every time? Yes. Other information: This bug is visible with both xorg and xsun on solaris.
Hi Tim: Do you have detailed instructions for how to configure the virtual frame buffer on Solaris Nevada?
Hi Will, you can refer to this link: http://sceri.prc.sun.com/desktop/Browser/QA/Test_Plan/Accessibility/Vermilion/magnifier-configure.html on x86 boxes, you could refer to the link: http://www.gnome.org/learn/access-guide/2.10/apas03.html
After some experimentation, I can the see the sluggishness even when not in full screen mode. Confirming this as a future RFE. Thanks!
Also: "gnome mag has finished a new feature supporting full screen magnification for XOrg composite extension. A user can use command line to start it such as "magnifier --ignore-composite=0 -f -m --smooth-scrolling". I think a user should also be able to start magnifier by ORCA configuration. For the new feature discusstion you can see http://bugzilla.gnome.org/show_bug.cgi?id=348375"
This bug is a bit of a mystery - since it was not noted with magnifier in standalone mode using VFB or dummy driver, and was not noted with gnopernicus magnification in the past. Might this have to do with the synchronous pointer-drawing logic that was added for orca? Mystery is, why is it worse when using two framebuffers? Tim, can you test with two physical framebuffers, to see if the results are similar?
http://sceri.prc.sun.com/desktop/Browser/QA/Test_Plan/Accessibility/Vermilion/magnifier-configure.html > on x86 boxes, you could refer to the link: > http://www.gnome.org/learn/access-guide/2.10/apas03.html These kind of helped me get going -- thanks! In reviewing this again, I think the lag may have gotten better in Nevada build 66. Can you please retest. If it still seems bad, can you quantify what you mean by lag? Is it on the order of seconds per frame refresh? In addition, do you know of a way to run just 'magnifier' with the dummy driver so we can evaluate what it does all by itself?
OK, I'll test magnification scenario with latest orca and neveda build, and give you update after testing. Thanks!
In e-mail with Tim, I think we're at the point where the magnifier in standalone mode is running faster than the magnifier as being driven by Orca. My guess with what's going on is due to the fact that Orca supports more mouse tracking features than the magnifier. It supports centered/push/proportional. As a result, Orca needs to listen for mouse motion events, make some decisions based upon these events, and then tell the magnifier what to magnify. This is all done via CORBA. If we were able to get the magnifier to support centered/push/proportional (and more?) modes, then Orca would not need to listen for mouse motion events and the magnifier could take care of mouse tracking directly. I suspect this might result in much better performance.
I changed Orca to doesn't update the pointer and the magnifier worked almost with the same performance, so I don't think that implementing the cursor tracking logic in gnome-mag will help much with this.
(In reply to comment #9) > I changed Orca to doesn't update the pointer and the magnifier worked almost > with the same performance, so I don't think that implementing the cursor > tracking logic in gnome-mag will help much with this. > How did you make this change (do you have a patch just for the purposes of discussion)?
Created attachment 93655 [details] [review] disable mouse drawing control throw orca I think that it's possible to implements the behaviour that orca does when it's controlling mouse drawing position directly within gnome-mag. I think that do this is much more reasonable and if we still have performance problems, then we can think in implement the mouse track logics directly in gnome-mag.
Created attachment 93675 [details] [review] Modification to disable any mouse tracking by Orca I think I see where we were thinking differently. If we can push the various pointer tracking modes into gnome-mag, we can eliminate the need for Orca to listen for mouse motion events. Here's a test patch that eliminates Orca's listening for mouse motion events. It currently doesn't allow any mouse tracking by anyone (Orca or gnome-mag) -- I'm not quite sure how to tell gnome-mag to take control. Carlos, do you know the magic incantations?
gnome-mag doesn't do mouse tracking, so it doesn't have interfaces to tell it to take control. I tested here again, disabling the calls to setPointerPos and percept some degradation in performance (more from what I percept in the last post), but I don't think that this is really a problem to users. My machine isn't that fast and the lag apparently doesn't appear to be big, so an user will consider a problem. Tim, do you have user critics about the lags that you percept? In Ubuntu forums and mailing lists I only saw compliments about how the mouse tracking was accurately in the latest versions of Orca.
(In reply to comment #7) > OK, I'll test magnification scenario with latest orca and neveda build, and > give you update after testing. Thanks! > Tim - is this still bad, as in it is much worse when running with Orca than when with running magnifier by itself?
Will, this is improved already after several builds magnifier scenario testing with composite extension enabled. The problem right now is the gnome mag bug #496355 Magnifier causes cpu usage much high, I think.
(In reply to comment #15) > Will, this is improved already after several builds magnifier scenario testing > with composite extension enabled. The problem right now is the gnome mag bug > #496355 Magnifier causes cpu usage much high, I think. > Thanks Tim! I'm going to close this bug out and we'll track the other problem via bug 496355.