Open Bug 404293 Opened 17 years ago Updated 2 years ago

images in the themes should be shipped at twice the required resolution

Categories

(Firefox :: Theme, defect, P4)

Product:
Firefox
Component:
Theme
Type:
defect

Tracking

()

People

(Reporter: db48x, Unassigned)

References

Details

As Firefox 3.0 approaches, more and more people are trying the beta. A number of them have discovered that we scale the chrome when their monitor has better than a 144 dpi, and have remarked that this makes the UI look too pixelated, as the images from the theme then have to be scaled up.

We should instead ship all of the images at twice the normal size. When the chrome is not scaled, these images will be scaled down by 2 in order to fit, leaving the UI looking the same as it does currently. On monitors with a high dpi, the images will already fit perfectly fine and will not be scaled either way, which will leave the UI looking as good as it did before.

Of course, this is just a stopgap until we can begin using SVG to define the UI.
Flags: blocking1.9?
Scaling down images on the fly would be terrible for both perf and appearance at normal resolution.  I think we should ship separate high-resolution images (like we currently do for large vs. small icons), if we do anything.
Blocks: 348059
(In reply to comment #1)
> Scaling down images on the fly would be terrible for both perf and appearance
> at normal resolution.  I think we should ship separate high-resolution images
> (like we currently do for large vs. small icons), if we do anything.
> 

How would that work though? Would we have to add a css selector that is keyed to the dpi?
WebKit's approach was to add a CSS media selector, "device-pixel-ratio".  So you can do things like

<link rel="stylesheet" media="screen and min-device-pixel-ratio: 2" href="highres.css"/>

See http://webkit.org/blog/55/high-dpi-web-sites/.
which operating systems change the resolution of UI widgets based on the DPI of the monitor?  I was under the impression that both Microsoft and Apple have yet to ship a resolution independent windowing system (with the exception being apps on Windows made using XAML).
It's unfortunate that CSS media queries did not make 1.9.

We could change the DPI at which pixel-doubling kicks in. If we made the threshold more like 200dpi, the pixel doubling would be less obvious.
Alex: no operating system does. Firefox and Safari are the only apps I know of that do it.

Roc: what would be involved in implementing additional css media types?
there's a patch for CSS media queries. The issue is not new media types, it's syntax for conditional queries
That's what I mean. What bug is it in?
>A number of them have discovered that we scale the chrome when their monitor has >better than a 144 dpi

I had no idea we were starting to do this, are we concerned that it will be odd that widgets in the Firefox chrome are appearing larger than every other application?  In general I agree that we should be doing this, but ideally we would tie into an OS options for specifying UI size (which of course won't be in place until Microsoft and Apple actually ship an OS that does resolution independent UI).

In terms of the request to recreate all icons at a higher resolution, I'm concerned that is really out of scope considering we have 120 icons being created for three platforms.  We could potentially create just the main window icons at a higher resolution, but if we are going to do this we really need to decide sooner rather than later.
(In reply to comment #11)
> In terms of the request to recreate all icons at a higher resolution, I'm
> concerned that is really out of scope considering we have 120 icons being
> created for three platforms.  We could potentially create just the main window
> icons at a higher resolution, but if we are going to do this we really need to
> decide sooner rather than later.

It should simply be a matter of rendering an extra set of icons from the source documents, at a different resolution. Right?
Not quite. Icons are generally re-rendered down, but then pixel-polished to get rid of scaling artifacts. There's a cost to our download size, as well.

Alex: let's talk about this early next week in terms of your deliverables for theme work.

Daniel: do you know what monitors are currently running into these issues? Major commercial offerings? Just wondering where you're seeing the reports.
Flags: wanted1.9+
Flags: blocking1.9?
Flags: blocking1.9-
Priority: -- → P4
> Daniel: do you know what monitors are currently running into these issues?
> Major commercial offerings? Just wondering where you're seeing the reports.

I am seeing that problem on Dell M4300 notebook with WUXGA monitor - the native resolution is 1920x1200 at about 145 DPI. As far as I see Dell notebooks from the Precision and XPS series generally have high res monitors.
Pixel-polishing might be less important at high resolutions, fwiw.
(In reply to comment #13)
> Not quite. Icons are generally re-rendered down, but then pixel-polished to get
> rid of scaling artifacts. There's a cost to our download size, as well.
> 
> Alex: let's talk about this early next week in terms of your deliverables for
> theme work.

Yea, Alex and I were talking about this on IRC the other day. Turns out that the bulk of the icons probably weren't created in vector form, and that we haven't been checking in the source files anyway. (even raster format source files with the original layers and so on could be useful to have around in the future.)

I had also been under the impression that vector art packages could do hinting in much the same way that modern fonts are hinted, which means that manual tweaking of the final render is unnecessary. Apparently this isn't the case, so it turns out that it's not just a matter of rendering the art to two different sizes.

> Daniel: do you know what monitors are currently running into these issues?
> Major commercial offerings? Just wondering where you're seeing the reports.

A lot of laptops are starting to push past 144 dpi, because they keep pushing the resolutions up while keeping the size of the display the same to save on weight. I happen to have a CRT that isn't quite 144dpi, and I set the gnome and firefox dpi settings up that high to counteract my failing vision.

I've seen a couple of questions in various forums in the past few days; irc, mozillazine, etc.
Let's just increase the DPI where we cut over to pixel-double to around 200dpi. So basically instead of computing the pixel multiplier by rounding (dpi/96), use floor instead (with a min of 1 of course).
Is there anyway to simulate having a higher DPI so I can recreate the issue being discussed (outside of buying a really fancy new monitor :)
(In reply to comment #17)
> Let's just increase the DPI where we cut over to pixel-double to around 200dpi.
> So basically instead of computing the pixel multiplier by rounding (dpi/96),
> use floor instead (with a min of 1 of course).

I really wouldn't want to do that. Are we going to keep pushing the threshold back just because people are surprised when it happens? I'd rather ship the way we are now.

(In reply to comment #18)
> Is there anyway to simulate having a higher DPI so I can recreate the issue
> being discussed (outside of buying a really fancy new monitor :)

Certainly. Simply set the pref 'layout.css.dpi' to 144 or 240. 


>  Are we going to keep pushing the threshold back just because people are
> surprised when it happens?

No, because with a screen dpi of 200 the regular UI is obviously unusable so people will be happier even if there's pixel-doubling (which will be less obvious since the screen pixels are smaller)
(In reply to comment #20)
> No, because with a screen dpi of 200 the regular UI is obviously unusable so
> people will be happier even if there's pixel-doubling (which will be less
> obvious since the screen pixels are smaller)

Also, if you do that I'll have to set my dpi to 200 just to keep the scaling that I like, which will make some pages misrender.
Maybe scaling should be a separate hidden pref?
Product: Core → SeaMonkey
This appears to be a Firefox bug but was accidentally moved to SeaMonkey. Moving back so it doesn't get lost again.
Component: Themes → Theme
Flags: wanted1.9+
Flags: blocking1.9-
Product: SeaMonkey → Firefox
QA Contact: themes → theme
The following flags went missing when I moved this bug back to Firefox:
blocking1.9-, wanted1.9+
For Mac OS X 10.7, double-resolution (HiDPI) screen modes are available, and Apple is now shipping a MacBook Pro with Retina display that uses them: see bug 674373.

Currently, -moz-device-pixel-ratio returns 1.0 here but it should return 2.0 (bug 765914) -- if that gets fixed, then chrome CSS could use media queries to pick the appropriate double-size assets.


Note that Windows 8 is also preparing some resolution-independence; for Metro apps the expected scale ratios are 1.4 and 1.8 (strangely enough...) it's less clear to me how desktop apps are to be handled for that environment.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.