Changing platform DPI handling
Robert O'Callahan
Right now we set the number of device pixels per CSS pixel to "max(1,
round(dpi/96.0))".
People complain about the rounding in that expression (e.g. in bug
426788) because it results in abrupt transitions between scale factors
when there are small changes in dpi.
The original motivation for rounding was to force the number of device
pixels per CSS pixel to be an integer, so that:
1) edges at CSS pixel boundaries would be crisp
2) objects whose dimensions are an integer number of CSS pixels would
always have consistent device pixel dimensions no matter where they are
rendered
3) for performance reasons, avoid scaling
Issue #1 has almost entirely been fixed by snapping rectangles to device
pixel boundaries, for the sake of zooming.
Issue #2 is arguably not a big deal especially if you have a high-dpi
screen.
For issue #3, all that really matters is that we use one device pixel
per CSS pixel whenever it's reasonable to do so (i.e. whenever dpi is
reasonably close to 96).
So I propose setting the number of device pixels per CSS pixel to "dpi <
192 ? 1 : dpi/96.0". I.e., the ratio stays at 1 as dpi increases until
it reaches 192, and then it jumps to 2 and increases smoothly with dpi
thereafter. Maybe we should lower that 192 threshold, though. Any comments?
Rob
Doug Turner
bit concerned about issue #3. on mobile, most (all?) of what we are
seeing are devices that have > 96 dpi. for example, the windows
mobile device I have in front of me has a dpi of 287. In this case,
we are forcing the device pixel per css px to be 1 in our preferences
(via layout.css.devPixelsPerPx). Do you imagine that mobile continues
to avoid this new handling using the above preference?
also, and probably unrelated, most of the linux devices we have seen
lie about their DPI -- all reporting 96 when asked. anywhere we
question the system about DPI, we should probably continue checking
application preferences (eg. layout.css.dpi).
doug
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
Robert O'Callahan
> bit concerned about issue #3. on mobile, most (all?) of what we are
> seeing are devices that have > 96 dpi. for example, the windows mobile
> device I have in front of me has a dpi of 287. In this case, we are
> forcing the device pixel per css px to be 1 in our preferences (via
> layout.css.devPixelsPerPx). Do you imagine that mobile continues to
> avoid this new handling using the above preference?
Yes.
> also, and probably unrelated, most of the linux devices we have seen lie
> about their DPI -- all reporting 96 when asked. anywhere we question the
> system about DPI, we should probably continue checking application
> preferences (eg. layout.css.dpi).
Sure, I assumed that.
Rob
Sylvain Pasche
> So I propose setting the number of device pixels per CSS pixel to "dpi <
> 192 ? 1 : dpi/96.0". I.e., the ratio stays at 1 as dpi increases until
> it reaches 192, and then it jumps to 2 and increases smoothly with dpi
> thereafter. Maybe we should lower that 192 threshold, though. Any comments?
Hi,
I was going to propose an alternative approach for managing DPI, but
that path is more involving (may require application changes) so it
should probably be addressed separately from your proposed change.
I'm using Windows in the examples below because there are well defined
guidelines for writing DPI aware applications [1], but that should apply
to other platforms as well. Basically, Windows has a concept of "logical
DPI" which is a way of scaling the whole UI by a certain factor. If you
configure the system to use 144 DPI (150% of 96 DPI), everything will be
150% larger in DPI aware applications (fonts, graphics, layouts).
However that's not the case in Gecko now. If you configure the system to
120 DPI (125%), the interface isn't scaled accordingly (only XUL font
size are resized, so the interface looks a bit funny). Scaling smoothly
the application XUL interface would make it look more like other DPI
aware applications.
For content, that's another story. Users may not like to view Web pages
when there isn't a 1:1 css pixel per device pixel mapping because of the
resulting blurry images. To solve this issue, I think applications
should offer a way in the UI to go to 1:1 css pixel per device pixel
zoom level easily (and maybe provide an option to have this scale by
default for all pages).
In fact that's what IE 8 does actually. If you configure your system to
150% DPI for instance, by default IE will show every pages scaled to
150% and give you a way to go to 100% with a UI element on the bottom of
the browser window.
So basically this could be achieved by setting the number of device
pixels per CSS pixel to max(1.0, dpi/96.0).
Then applications would use nsIDOMWindowUtils.screenPixelsPerCSSPixel to
scale content to a 1 device pixels per CSS pixel scale if needed, by
doing something like:
nsIMarkupDocumentViewer.setFullZoom(1/nsIDOMWindowUtils.screenPixelsPerCSSPixel)
They would also use screenPixelsPerCSSPixel for displaying the current
scale in percent using screenPixelsPerCSSPixel * 100.
(an alternative would be to make a distinction between XUL and content,
and use separate device pixels per CSS pixel values in both so that
content is always shown with a device pixels per CSS pixel scale of 1 by
default, but that seems more complex to implement and if we want to zoom
content by default to match the OS setting more work is needed).
Lastly, the application should also provide higher resolution images for
the theme, so that the interface doesn't look blurry with high DPI.
(maybe implement min-device-pixel-ratio media query in order to use the
most suitable theme image).
Does this sound reasonable?
Sylvain
[1] http://msdn.microsoft.com/en-us/library/dd464660%28VS.85%29.aspx
Robert O'Callahan
> I'm using Windows in the examples below because there are well defined
> guidelines for writing DPI aware applications [1], but that should apply
> to other platforms as well. Basically, Windows has a concept of "logical
> DPI" which is a way of scaling the whole UI by a certain factor. If you
> configure the system to use 144 DPI (150% of 96 DPI), everything will be
> 150% larger in DPI aware applications (fonts, graphics, layouts).
>
> However that's not the case in Gecko now. If you configure the system to
> 120 DPI (125%), the interface isn't scaled accordingly (only XUL font
> size are resized, so the interface looks a bit funny). Scaling smoothly
> the application XUL interface would make it look more like other DPI
> aware applications.
Do those DPI aware applications actually scale 32x32 icons up to 40x40?
That sounds nasty.
Rob
Sylvain Pasche
>
> Do those DPI aware applications actually scale 32x32 icons up to 40x40?
> That sounds nasty.
What Microsoft suggests is to provide multiple icons for each resolution
[1], and then select the icon that best fits the target resolution.
That's what IE does for instance (I'm not sure how many icon versions
they have, but the icons at 150% are not the same as the 100% version).
Having to ship 4 versions of each theme image looks like a big pain.
Maybe we could go only with 2 versions (low-res/high-res) without too
much blurriness.
Sylvain
[1]
http://msdn.microsoft.com/en-us/library/dd464660%28VS.85%29.aspx#scaling_graphics
Nelson Bolyard
The system resolution is set to that value.
It looks pretty good in the OS displays an in many programs.
I wish I could say it looks good in Firefox, but ... it doesn't.
I often must adjust the zoom of fonts to make them readable.
Robert O'Callahan
> On 8/25/2009 3:01 AM, Robert O'Callahan wrote:
>> Do those DPI aware applications actually scale 32x32 icons up to 40x40?
>> That sounds nasty.
>
> What Microsoft suggests is to provide multiple icons for each resolution
> [1], and then select the icon that best fits the target resolution.
> That's what IE does for instance (I'm not sure how many icon versions
> they have, but the icons at 150% are not the same as the 100% version).
>
> Having to ship 4 versions of each theme image looks like a big pain.
> Maybe we could go only with 2 versions (low-res/high-res) without too
> much blurriness.
Microsoft's page is rather confusing. They seem to suggest that you
support 96, 120 and 144 DPI (suggesting without actually saying that
these are the only possibilities you should worry about), and support
other possibilities by downscaling the next largest image you've got.
If we don't want to immediately go down the route of creating and
shipping 2-3 versions of each image in our themes, I think we should go
with my original plan, and separately address this problem of making our
UI look nice at 144 DPI. One option there might be to offer separately
installable themes designed for that situation.
Rob
Sylvain Pasche
> I have a large old display with 86 DPI (83% of 96 DPI) for my old eyes.
> The system resolution is set to that value.
What OS are you using? Windows since Vista don't allow setting the DPI
to less than 96 apparently.
> It looks pretty good in the OS displays an in many programs.
> I wish I could say it looks good in Firefox, but ... it doesn't.
> I often must adjust the zoom of fonts to make them readable.
Do you mean that text is too small in Firefox? I would expect it to be
larger than in other applications which would be scaled down to 83% of
96 DPI. But it could just be that many sites are using small pixel font
sizes (I usually set the minimum font size to 11px to avoid this).
Sylvain
Sylvain Pasche
> If we don't want to immediately go down the route of creating and
> shipping 2-3 versions of each image in our themes, I think we should go
> with my original plan, and separately address this problem of making our
> UI look nice at 144 DPI. One option there might be to offer separately
> installable themes designed for that situation.
Sounds like a good plan. I think it would be nice to go with your plan,
but still provide a way to have the UI scaled smoothly for users who
don't care about blurry theme images or to let users test an optional
high-dpi theme before that smooth dpi change is made to trunk.
I see two options for doing this.
1) Have a pref that toggles between "dpi < 192 ? 1 : dpi/96.0" or
"dpi/96.0" for the number of device pixels per CSS pixel.
2) Make layout.css.devPixelsPerPx float.
I noticed that there isn't a float type for preferences, so what we
could do is call the pref layout.css.devPixelsPer100Px so you could set
it to 150 in order to have a UI zoomed by 150%.
Sylvain
fantasai
We define 1 image pixel == 1 CSS px unit. How happy will designers be
with the resulting image displays, that no longer align on pixel
boundaries?
~fantasai
Robert O'Callahan
> 2) Make layout.css.devPixelsPerPx float.
> I noticed that there isn't a float type for preferences, so what we
> could do is call the pref layout.css.devPixelsPer100Px so you could set
> it to 150 in order to have a UI zoomed by 150%.
Or you can make it a string and we can parse it as a float in the code.
I'd take a patch for that.
Rob
Robert O'Callahan
> We define 1 image pixel == 1 CSS px unit. How happy will designers be
> with the resulting image displays, that no longer align on pixel
> boundaries?
The area filled by the image will still be snapped to pixel boundaries
at draw time. It will behave like we do with zooming today, which seems
to be acceptable.
Rob
Honza Bambas
> So I propose setting the number of device pixels per CSS pixel to "dpi
> < 192 ? 1 : dpi/96.0". I.e., the ratio stays at 1 as dpi increases
> until it reaches 192, and then it jumps to 2 and increases smoothly
> with dpi thereafter. Maybe we should lower that 192 threshold, though.
> Any comments?
>
(and I agree with it) to be able to set dpi in interval <1,2> smoothly,
that means to be able to set dpi to 96, 97 etc to 191, 192. The "dpi <
192 ? 1 : dpi/96.0" condition breaks that original request.
About icons, I don't think there is need to have different themes for
each dpi intervals, at least at the first stage. When you set dpi to a
higher value you probably, in most cases, do it because the default
value makes icons and text too small on your screen as it is large
having high dpi. When icons are enlarged and distort by this "zoom" it
should not be that much visible on such large screens. It will just get
a bit blurry as on a TV screen...
-hb-
kylek
>
> I see two options for doing this.
> 1) Have a pref that toggles between "dpi < 192 ? 1 : dpi/96.0" or
> "dpi/96.0" for the number of device pixels per CSS pixel.
>
> 2) Make layout.css.devPixelsPerPx float.
> I noticed that there isn't a float type for preferences, so what we
> could do is call the pref layout.css.devPixelsPer100Px so you could set
> it to 150 in order to have a UI zoomed by 150%.
>
Umm, what's wrong with simply using the dpi value specified in
layout.css.dpi? I don't understand why we even need an equation to
interpret the given value. This current equation is breaking my
experience with web content on my 15.4 WUXGA+ (1920x1200 - 147x145dpi)
laptop display. The UI itself looks great and obeys the dpi setting
of my Gnome fonts (gconf: /desktop/gnome/font_rendering/dpi). Now if
only the web content itself was rendered the same way I'd be a very
happy user.
BTW, I've logged https://bugzilla.mozilla.org/show_bug.cgi?id=512522
to ask for this functionality.
Sylvain Pasche
> About icons, I don't think there is need to have different themes for
> each dpi intervals, at least at the first stage. When you set dpi to a
> higher value you probably, in most cases, do it because the default
> value makes icons and text too small on your screen as it is large
> having high dpi. When icons are enlarged and distort by this "zoom" it
> should not be that much visible on such large screens. It will just get
> a bit blurry as on a TV screen...
Here's how it looks with the current theme at 150% font size using
"dpi/96.0" for the number of device pixels per CSS pixel:
http://www.spasche.net/files/ff_ie_zoom_150.png
That doesn't sound too bad to me, but I could understand that some
people may not agree.
Another option for the short term (i.e. not requiring a theme change)
may be to always use 1 device pixels per CSS pixel and to zoom Web pages
by default to match the OS zoom level. For instance, if you have a
144DPI setting, web pages would be zoomed by 150% by default (probably
with an option to turn that off).
Sylvain
Sylvain Pasche
> Umm, what's wrong with simply using the dpi value specified in
> layout.css.dpi?
I think that's the long term plan (on Windows at least). Right now these
two issues may be blocking that:
1) Provide high resolution image in the theme to avoid blurry images
2) Have a UI to go to 100% zoom level and maybe an option to make a 100%
zoom the default for users who don't like to see blurry images (and who
don't want to use "zoom text" only).
Here's how it looks at 150% dpi with smooth dpi on Windows:
http://www.spasche.net/files/ff_ie_zoom_150.png
Now for Linux, things may be a bit different. GTK doesn't provide
resolution independence yet, so if you have a dpi set to 144 the Firefox
icons will be 150% larger but they will stay at the same size on all
other GTK applications.
So until GTK has resolution independence, the right approach might be to
not to scale the XUL UI, but have a default zoom level for web pages
that matches the current DPI. For instance if you have a 144DPI
configuration pages would be zoomed by default to 150%.
Sylvain
Robert O'Callahan
> That doesn't sound too bad to me, but I could understand that some
> people may not agree.
Thanks for the screenshot. It looks OK to me too but if you zoom in you
can see it's not perfect. A lot of people are more picky about these
things than I am.
I think probably the best idea is to give the application full control
over these decisions. I need to think about the best way to do that.
Rob
Nelson Bolyard
> On 8/25/2009 8:07 AM, Nelson Bolyard wrote:
>> I have a large old display with 86 DPI (83% of 96 DPI) for my old eyes.
>> The system resolution is set to that value.
>
> What OS are you using? Windows since Vista don't allow setting the DPI
> to less than 96 apparently.
WinXP SP2
>> It looks pretty good in the OS displays an in many programs.
>> I wish I could say it looks good in Firefox, but ... it doesn't.
>> I often must adjust the zoom of fonts to make them readable.
>
> Do you mean that text is too small in Firefox?
Either too large or too small. Varies by page.
> I would expect it to be larger than in other applications which would be
> scaled down to 83% of 96 DPI.
That may explain Bug 396774
L. David Baron
> Umm, what's wrong with simply using the dpi value specified in
> layout.css.dpi? I don't understand why we even need an equation to
> interpret the given value. This current equation is breaking my
Well, one big reason is that that preference now does two different
things, and there's a desire to control those independently.
The original use of that preference was to control the ratio used to
convert CSS physical units (e.g., 'pt', 'in', 'cm', 'mm', etc.) to
pixels.
Recently, we started using it for a second purpose, which was to
control the number of CSS pixels per device pixel. We change the
number of CSS pixels per device pixel when the display is higher
than 144dpi (or something around there). The CSS spec actually says
that CSS pixels should be scaled based on viewing angle, not
physical distance, which probably provides a better accounting for
mobile devices than our current heuristic does. We could perhaps
emulate this by checking for small screen sizes in our heuristic as
well. However, the important point is that people want independent
control of this value.
(Though perhaps we should just fix the first one to always be 96 CSS
pixels per inch, and just change the second.)
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Robert O'Callahan
> However, the important point is that people want independent
> control of this value.
We offer it, via layout.css.devPixelsPerPx.
Rob
Sylvain Pasche
> I think probably the best idea is to give the application full control
> over these decisions. I need to think about the best way to do that.
I think they could make these decisions by setting the right prefs,
after a few small backend changes have been made.
* On Windows, if we want a high-DPI theme:
1) set the number of device pixels per CSS pixel to "dpi/96.0"
2) use the default prefs for layout.css.devPixelsPerPx and layout.css.dpi
Then if the app wants to display pages at 1 device pixels per CSS pixel,
they can set the fullzoom level to
1/nsIDOMWindowUtils.screenPixelsPerCSSPixel.
* On Linux, without scaling the theme images (because that would look
very odd in comparison to other applications that don't have such a
behavior):
1) set the pref layout.css.devPixelsPerPx to 1 (XUL font size will still
match the system setting, according to
https://bug512522.bugzilla.mozilla.org/attachment.cgi?id=396511)
If the app wants to zoom content by default to match the OS dpi level
(and so address issues such as bug 512522, where the font size in
content is too small in comparison to the system font size):
- expose the current system DPI setting
- zoom pages by system_dpi / 96.0
This differs from the current behavior on Linux if you have a DPI
setting >= 192: you will still use 1 device pixels per CSS pixel in that
case. If we want to keep the current behavior, there could be a pref for
keeping the current algorithm.
* on Mac:
I heard there is resolution independence in snow leopard now. I wonder
how Firefox deals with it, and if higher-res theme images will also be
needed to look good.
I'm sure there are other ways of addressing this, this one option
minimizing backend changes. Another approach could be to manage
zoom/device pixels per CSS pixel value independently for content vs XUL.
Sylvain
Neil
> Then if the app wants to display pages at 1 device pixels per CSS
> pixel, they can set the fullzoom level
The fullzoom level has UI; how would this affect it?
--
Warning: May contain traces of nuts.
Sylvain Pasche
> Sylvain Pasche wrote:
>
>> Then if the app wants to display pages at 1 device pixels per CSS
>> pixel, they can set the fullzoom level
>
> The fullzoom level has UI; how would this affect it?
The problem with the current UI (in Firefox) is that if the default zoom
level is not 100% (for instance if we want to behave like IE and zoom by
default to match the system zoom level), then there's no easy way to go
to 100%.
When you browse with a default zoom level that is not 100%, it's
sometimes useful to zoom to 100% on a page if you don't want to see
blurry images (if "zoom text only" is off) or if you want to see the
page layout exactly as the designer created.
The current UI doesn't show the current zoom level, so you would have to
zoom out a few times and stop when you think you hit 100%.
I've posted some proposals in mozilla.dev.usability [1] how this could
be addressed.
Sylvain
[1]
http://groups.google.com/group/mozilla.dev.usability/browse_thread/thread/90cb8fc382574b90