GNOME Bugzilla – Bug 710194
Magnifier: View is poor quality because the image is not scaled
Last modified: 2021-07-05 14:15:51 UTC
It is tricky but can be done: texworks (my humble opinion) scale pdf images really beautifully.[1] Even if we could just start with the scaling of document reading and writing it would mean a significant improvement since people really need to be able to focus their eyes for longer periods of time when doing this. [1] http://code.google.com/p/texworks/
Right, the issue is that windows are bitmaps that we scale up, and there's no easy way of telling them to up the scale without resizing the entire window. This is something we could fix in Wayland.
We could start with a specific magnified region and move outwards as we get that working properly here is the file that does it in texworks https://paste.fedoraproject.org/47012/86735113/ Note, this line in particular: if (page != imagePage || dpi != imageDpi || loc != imageLoc || size != imageSize) image = page->renderToImage(dpi, dpi, loc.x(), loc.y(), size.width(), size.height()); Seems to perform a test to make sure that the scaling is relative to its surroundings (I think - I am not very confident with C). Should I ask the developers for some advice?
Oh and regarding wayland, I asked one of the developers a bit about this in GUADEC but I understood very little of his response but: I always had in the intention of getting wayland set up in jhbuild once SOC was over so I could make sure the magnifier is fully integrated. I really only have a vaugue idea that it is a compositor using 3D acceleration so my guess is that the graphics will be easier to handle in there. However, I have no idea how far it is with regard to handling mouse, caret and focus tracking events and atspi in general. I wouldn't mind some pointers to the trustworthy documentation on that - any tips would be more than welcome really!
Created attachment 263104 [details] [review] switch to scaling-factor key and do away with mag-factor A solution for this has been found, I believe. It is going to be a lot easier than I originally thought thanks to the great work of Alexander Larsson with a simple yet affective key called scaling-factor... Delighted! I have the first part done but it needs to wait on g-s integration and a small change in gnome-control-center. Please note that this first patch should not be pushed to master until those other two are ready, in particular the gnome-shell patch as it needs to use a different schema and will break if the patch is in before that is done however, those changes will not depend on this one since the key is there now. Not sure whether this needs a bug for each module but I am happy to do that if required.
Sorry, forgot to provide a link to Alexander's patch! https://git.gnome.org/browse/gsettings-desktop-schemas/commit/schemas/org.gnome.desktop.interface.gschema.xml.in.in?id=7d296fd3af26f2d315d94c04dd8116e1ca09cebd
By the way, I should also mention that the control-center patch needs to wait for the gnome-shell one to be done too. Then they can be tested at the same time. Note also that switching to scaling factor will mean the equation for the magnifiers zooming will need to change quite significantly to allow a smooth zooming but I cannot foresee this being an issue.
scaling-factor is designed for HiDPI devices, and *only* allows for a 1x/2x scale, and not anything in between. It's possible rendering apps at 2x and scaling down would be better than rendering apps at 1x and scaling up, but I'm not so sure it would be that effective. It also only works with compliant (read: GTK+3) apps, and I don't think there's a way to tell whether an app supports the scaling-factor or not. It's not designed to solve the magnifier problem.
(In reply to comment #9) > scaling-factor is designed for HiDPI devices, and *only* allows for a 1x/2x > scale, and not anything in between. It's possible rendering apps at 2x and > scaling down would be better than rendering apps at 1x and scaling up, but I'm > not so sure it would be that effective. > I understand that, but it is a problem eclipsed by the degraded view the magnifier is currently presenting me with. Besides, the scale-factor key has been tested on several apps already just today. What I found was that every single time it significantly out performed the current magnifier zoom and, it did so in just about every way, the scaling was even better than I would have expected actually: Not only does the new scale-factor key solve the magnifiers poor dpi problem, but I found that it also gives an the zooming is infinitely better proportioned view. The magnifier just seems to give tiny text and a massive blob of background. The focus tracking has to be turned off for document writing as high zoom or you just cannot read the text. In other words, the view is degraded and the keynav is a nuisance (think commodore 64). Now, I am not saying scaling key is perfect, sure it had a few things to sort out as well, but as I said, it is most certainly usable, where the magnifier view is awful, broken even. Please try this out for yourself before you dismiss the idea. It only takes a second to see that the magnifier is not up to standard. > It also only works with compliant (read: GTK+3) apps, and I don't think there's > a way to tell whether an app supports the scaling-factor or not. > > It's not designed to solve the magnifier problem. The wheel was not designed for cars but that happened. Most innovations happen during wartime for that matter, I am not sure this is enough of a reason to rule out making use of something that works better than what you have already. Try it because you will see what I mean if you do, I am sure of it. gsettings set org.gnome.desktop.interface scaling-factor 2 2 I think is a good one to start with, once you compared that to the magnifier test you will probably see why it is better to change to using the dpi scaling key - or at the very least, I guess I could try to re-model mag-factor to do the same thing, but that seems a bit unnecessary.
Changing the scaling factor reduces the area of the desktop, which, in my underestanding is not something that people who need a magnifier generally want. Applications may not fit properly into the screen if you reduce its effective dimensions by a factor of 2 or 3. Changing the scaling factor won't help with non-GTK+ applications, so if we use this rather than the magnifier, we will make these applications inaccessible. The two questions I have here are: - Have you discussed quality with people with visual impairments? While the appearance of a pixel-by-pixel scaled up window is not pleasant to someone with normal vision, if the primary problem that the user has low visual acuity, they might still find it usable. - You seemed to say on your blog that something got much worse after GNOME 3.10. As far as I know, nothing was supposed to have changed, and quality now is the same as it always ways. Maybe we should track down what changed? Can you try reverting the Mutter commit: commit 8af0e10aa4918fa0e6b59c41e643a2b5a48bf0d3 Author: Hans Petter Jansson <hpj@cl.no> Date: Thu Oct 10 02:38:52 2013 +0200 shaped-texture: Use nearest-pixel interpolation if the texture is unscaled It's not supposed to change anything for the magnified case, and I don't see why it would, but it does appear that you are getting nearest-pixel interpolation. With Wayland especially, it should eventually be possible to magnify like we do know but allow applications to provide a rerendered version of the magnified area to be displayed instead of a magnified version.
(In reply to comment #11) > Changing the scaling factor reduces the area of the desktop, which, in my > underestanding is not something that people who need a magnifier generally > want. This is already happening. > Applications may not fit properly into the screen if you reduce its > effective dimensions by a factor of 2 or 3. They don't > Changing the scaling factor won't help with non-GTK+ applications, so if we use > this rather than the magnifier, we will make these applications inaccessible. Hmm I have tried with some QT applications with no trouble. What is it exactly that makes it non-GTK+ compatible. Also, I am not suggestion we not use the magnifier, I am suggesting we could use the scaling-factor instead of the mag-factor which as is currently used and is not producing a decent image. > The two questions I have here are: > > - Have you discussed quality with people with visual impairments? While the > appearance of a pixel-by-pixel scaled up window is not pleasant to someone with > normal vision, if the primary problem that the user has low visual acuity, they > might still find it usable. This has been a great challenge for me. Asking on the lists hasn't brought too much joy. I believe this is because too many users are still on 3.8 which is why I have turned to statistics. I can try again though bbut I think my best bet might be to get in touch with Royal Institute for the Blind or some similar group of experts and find out what they think. For the record though, my own vision is not 20/20. I wear tints for visual stress. That said, it is not possible at this time to know whether this means the problem is amplified to me or not since so few others seem to have tried it and fed back. > - You seemed to say on your blog that something got much worse after GNOME > 3.10. As far as I know, nothing was supposed to have changed, and quality now > is the same as it always ways. Maybe we should track down what changed? Can you > try reverting the Mutter commit: I will try this and let you know, though my desktop is running 3.10 so might need to manually do something to get it going. > commit 8af0e10aa4918fa0e6b59c41e643a2b5a48bf0d3 > Author: Hans Petter Jansson <hpj@cl.no> > Date: Thu Oct 10 02:38:52 2013 +0200 > > shaped-texture: Use nearest-pixel interpolation if the texture is unscaled > > It's not supposed to change anything for the magnified case, and I don't see > why it would, but it does appear that you are getting nearest-pixel > interpolation. > Ok that is interesting. Thanks. If we can narrow it down to this then perhaps trying a different equation for zooming in magnifier.js to account for this change could be what's needed to improve matters somewhat. > With Wayland especially, it should eventually be possible to magnify like we do > know but allow applications to provide a rerendered version of the magnified > area to be displayed instead of a magnified version. Sorry, can you clarify this?
(In reply to comment #12) > (In reply to comment #11) > > Changing the scaling factor reduces the area of the desktop, which, in my > > underestanding is not something that people who need a magnifier generally > > want. > > This is already happening. No, currently the actual desktop size (as exposed to applications) stays the same. When the magnifier is active, parts of the desktop just end up off-screen, but that's completely transparent to applications. Another concern that I have not seen raised before would be non-default screen positions - how would the scaling factor work if only half the screen should be magnified?
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > Changing the scaling factor reduces the area of the desktop, which, in my > > > underestanding is not something that people who need a magnifier generally > > > want. > > > > This is already happening. > > No, currently the actual desktop size (as exposed to applications) stays the > same. When the magnifier is active, parts of the desktop just end up > off-screen, but that's completely transparent to applications. > Ok, but the outcome is the same for the user and, since we were talking 'user experience' I still would say, it is the same i.e. some parts of the desktop are out of view. > > Another concern that I have not seen raised before would be non-default screen > positions - how would the scaling factor work if only half the screen should be > magnified? Good point. The texlive example I gave above only works on a portion of the view (a circular region) and leaves the rest of the view unmagnified, (I would like to see something like that become an option at some point.) Again, it would be useful to know how users are interacting with the current settings and find out more about that. I would say integrating into the caret tracking might be a first step (not certain about focus tracking right now) but the mouse probably ought to be handled as it currently is until more is known since it is going to be more likely used with icons which currently are not being scaled by the scale-factor, it seems. I do think the caret tracking needs this most because of the problems I expect a low quality font is going to offer for reading and writing of documents. Both the text-scaling-factor key and the scaling-factor key seems to work well at present with the scaling-factor. However, while the icons are not right there's not going to necessarily be an advantage to changing, at least until more is known.
(In reply to comment #11) > - Have you discussed quality with people with visual impairments? While the > appearance of a pixel-by-pixel scaled up window is not pleasant to someone with > normal vision, if the primary problem that the user has low visual acuity, they > might still find it usable. Further to my previous response to this WebAim have some guidance which should hopefully make sense http://webaim.org/techniques/images/#enlarging
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.