GNOME Bugzilla – Bug 676814
make 'zoom' independent of color-related shader use
Last modified: 2021-07-05 14:22:07 UTC
Currently, to make use of the newly merged brightness, contrast and lightness shaders, one has to turn on the magnifier, and if you are only interested in the color modification, set the zoom to fullscreen with zoom factor 1.0. That is rather unintuitive - the color modifications should be available independently of the magnifier, we want to expose them as independent controls in the universal access panel. One way to go about this would be to refactor magnifier.js a bit, and turn it into a more general 'shader effects' support, and make the shader support implicitly enabled when either zoom or any of the color modifications are turned on.
(In reply to comment #0) I'm reluctant to do this, but not dismissing it completely. > That is rather unintuitive - the color modifications should be available > independently of the magnifier, we want to expose them as independent controls > in the universal access panel. It's not unintuitive to magnifier users. They used tothe idea that a zoomer is what to use for, say, inverse video. Screen magnifiers are mis-named. They do more than just "zoom" the screen. They also make the mouse pointer image easier to see (e.g., magnify and/or crosshairs), they alter brightness and contrast, and some modify fonts. They are better described as screen or display enhancers. Nonetheless, here are some possible ways to address re-factoring: The label on the UAP toggle is currently "Zoom". If it were changed to something like "Screen enhancements", that might be enough. A second possibility is to have two "activate" gsettings. One is for "activate zoom" and the other is "activate colour changes". Both are ultimately connected to the magnifier's setActive() method. But, that doesn't address your example of a user who wants only colour effects since as soon as they activate the magnifier, all settings are asserted, including "zoom" settings. That argues for adding the colour effects to the zoom options dialog so they can be addressed at once (ie. no re-factoring). A third way is to have both setZoomActive() and setColourEffectsActive() properties in the magnifier, that (1) both activate the magnifier, and (2) activate only the colour effect XOR only the zoom effects. However, how do you tell the difference between a user who, for example, wants both 5x magnification and inverse video, vs. a user who wants inverse video only? Do they have to open two separate dialogs for these different settings/functions of the magnifier? That's not ideal. Still thinking about this...
Ok, I get the point about 'screen enhancer'. But one aspect in which zoom and contrast/color/etc modifications are different is that for zoom, having it restricted to a part of the screen seems important, while the other modifications would do better if they apply to the entire screen. Or is that not the case ? When Jon and I looked at OS X, the inverse and grayscale options were not tied to zoom, I think...
http://etc.usf.edu/techease/wp-content/uploads/2009/12/display2.png
(In reply to comment #2) > Ok, I get the point about 'screen enhancer'. But one aspect in which zoom and > contrast/color/etc modifications are different is that for zoom, having it > restricted to a part of the screen seems important, while the other > modifications would do better if they apply to the entire screen. Or is that > not the case ? I see the point, but they are not that tightly linked. Yes, screen real estate becomes relatively more important when you start increasing the mag factor, and not so much if you are just using colour effects. One use case I cited had the user choosing both zoom and inversion: if the user chooses, say, the top-half screen position preference, should the inversion apply to the entire screen and the zoom just to the top half -- that they cannot see the original view any longer? > > When Jon and I looked at OS X, the inverse and grayscale options were not tied > to zoom, I think... If you are looking at OS X Lion, do the following: under Zoom, check the "Zoom in window" checkbox. Then click the "Options..." button. The dialog that comes up includes a checkbox for inversion, and that checkbox is among various "zoomer" preferences. OS X both separates the inversion effect from other zoomer settings, *and* integrates them. FWIW, I find OS X's Magnifier dialogs confusing and awkward. However, if we decide to go with "effects apply to the whole screen", I think it can be done if they are applied to the uiGroup object, while the other enhancements are on a clone. That might work.
(Followup to comment #4) > If you are looking at OS X Lion, do the following: under Zoom, check the "Zoom > in window" checkbox. Then click the "Options..." button. The dialog that > comes up includes a checkbox for inversion, and that checkbox is among various > "zoomer" preferences. Screenshot: http://clown.idrc.ocad.ca/aegis/GS-Mag/LionZoomOptions.png
My concern with re-factoring is how long it might take, and, that users have to wait to easily access these effects. They are part of the magnifier, and it's not absolutely wrong if they are confined to the magnifier view. In terms of UI, what could be done in the short term is adding a set of controls to the existing "Zoom Options" Panel: - a toggle for inversion. - a slider for brightness - a slider for contrast - a slider for grey scale. Then, in the long term, if we want, separate these out into the "Display" section of the UAP. Addendum: I think users want to decide this for themselves. Some prefer that the colour effects are localized to the magnified view, whereas others want them applied across the entire screen. But, that's an additional preference complication to consider in the even longer term.
Sure, I agree that having some form of control for this is a good first step.
I've worked with users who have needed: * a split screen (e.g. left-half unmagnified, right-half magnified) * inverse brightness in just the magnified half The use case is document editing/desktop publishing in which seeing what the document truly looks like is important. For users in this situation, the unmagnified, non-inversed half showed more of the "real" screen contents (spatially and in terms of the real colors). But the text was too small to be read and the screen too bright to be viewed for a sustained period. Thus to read and write, the magnified and inverse brightness was required. Long way of saying: I totally see the value in separating "inverse" from "zoom". (Especially being a user who needs inverse and does not need or want zoom.) BUT, I would hate to see us wind up with a solution in which we had an all-or-nothing inverse for users such as described above.
It seems to me that it would be better to have these options in the universal access panel, but I won't object to having them in zoom options as an initial step.
So, I guess we mostly agree that it would be better in the medium term, to: - Move the color effects out of the zoom dialog - Have a checkbox like [ ] Color effects apply only to zoom area
I agree; I think this is important since we removed the ability to set High Contrast Inverse and Low Contrast themes from the Universal Access panel (and removed the corresponding GTK themes from gnome-themes-standard).
*** Bug 661701 has been marked as a duplicate of this bug. ***
Here is a link to an old but open bug, to provide example of the use for when you might not want magnification but would want the brightness/contrast control: https://bugzilla.gnome.org/show_bug.cgi?id=596386 I cannot comment on the inverted colours, but I definitely think the brightness/contract should not stay in the zoom settings as the initial report suggests it is unlikely to be clear that these features are available to anyone who is not a magnifier user. Simply because a person would need to look in the magnifier zoom settings to find out they were there. I am not just thinking of those with various reading difficulties but also migraine sufferers, and perhaps those with epilepsy, who may also benefit from having easy/obvious access to these settings and/or anyone else, really. I would actually like to solve this, but I am not sure what the status is now. It seems to have been left in the air since the last post was a year ago... Can anyone clarify? Is the idea still in debate, is someone already working on it?
Created attachment 271548 [details] color effects should not be part of zoom I only need to use invert colors to read a lot of text online (e.g., wikipedia) Now why is zoom a condition for inverted colors? I don't want to use zoom for color inversion. Why should anyone be made to use zoom for color effects? which is a separate feature, independent of zoom. Zoom has terrible performance issue. just enable zoom at 100% and see the mouse pointer lags, overall performance drops; Invert colors (color effects) should be a part of Universal access menu. Thanks.
*** Bug 693692 has been marked as a duplicate of this bug. ***
Decoupling the settings for zoom and color in the ui will not magically make the color implementation more performant. What you see now with zoom factor 1 is what you'll get. Unless somebody works on the performance
Decoupling will at least put the option where it is supposed to be and not buried inside universal-access and zoom. > Unless somebody works on the performance As I came to know from Jasper St. Pierre [gnome-shell developer] in bug 725548 "No, there are no full-time engineers working on performance tuning. We know that there are performance issues,..." No developer works for performance tuning. That's a shame! Performance comes under QA, no? Redhat Quality Assurance team does know this?
(In reply to comment #17) > No developer works for performance tuning. That's a shame! > > Performance comes under QA, no? Redhat Quality Assurance team does know this? You misquoted Jasper there. We will be more than happy to review your performance improvement patches.
(In reply to comment #16) > Decoupling the settings for zoom and color in the ui will not magically make > the color implementation more performant. What you see now with zoom factor 1 > is what you'll get. Unless somebody works on the performance I am not sure about that. 618397 seems to be at least partly responsible for the issues mentioned in comment 14 link https://bugzilla.gnome.org/show_bug.cgi?id=618397
The Laggy mouse pointer movement in Zoom is fixed by this extension. https://extensions.gnome.org/extension/987/magnifier-improvements/ Please consider using the fix from the extension. With this magnifier-improvement extension, zoom and invert works as expected. Thanks.
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.