Firefox 18 is now available
| From: | Bhavana Bajaj <bbajaj-AT-mozilla.com> | |
| To: | announce-AT-lists.mozilla.org | |
| Subject: | Firefox 18 is now available | |
| Date: | Tue, 8 Jan 2013 08:49:20 -0800 (PST) | |
| Message-ID: | <2005157474.33502106.1357663760134.JavaMail.root@mozilla.com> |
Firefox 18 is now available as a free download for Windows, Mac, and Linux from http://www.mozilla.org/firefox/new/. As always, we recommend that users keep up to date with the newest version of Firefox for the latest features and fixes. The release notes for Firefox 18 are available at http://www.mozilla.org/en-US/firefox/18.0/releasenotes/. Firefox 18.0 is also now available for Android. The associated release notes are available at https://www.mozilla.org/en-US/mobile/18.0/releasenotes/. - Bhavana Bajaj Release Manager at Mozilla _______________________________________________ announce mailing list announce@lists.mozilla.org https://lists.mozilla.org/listinfo/announce
(Log in to post comments)
Retina display support
Posted Jan 9, 2013 9:52 UTC (Wed) by epa (subscriber, #39769) [Link]
Retina display support
Posted Jan 9, 2013 10:30 UTC (Wed) by roc (subscriber, #30627) [Link]
We have some support for that for Windows, but it's currently disabled because of a few major bugs.
It would be pretty easy to extend to Linux/X11 too, except we don't know exactly which system setting(s) to observe to know when to automatically zoom.
Retina display support
Posted Jan 9, 2013 11:03 UTC (Wed) by epa (subscriber, #39769) [Link]
It means we render everything at the device resolution, so CSS 1px x 1px renders as 2x2 device pixels. It's kinda like having a default zoom.Thanks for the explanation. At work I run Firefox on Windows on a high-resolution display, and use Ctrl-+ to zoom in, which magnifies both the text and the images. Is that equivalent?
Retina display support
Posted Jan 9, 2013 12:50 UTC (Wed) by roc (subscriber, #30627) [Link]
Retina display support
Posted Jan 9, 2013 17:45 UTC (Wed) by nye (guest, #51576) [Link]
Is there any way for a site author to 'opt-out' of this? Maybe something involving a media-dependent stylesheet or something.
Retina display support
Posted Jan 9, 2013 18:41 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Yup. It's not that terrible in practice, but definitely not optimal.
> Is there any way for a site author to 'opt-out' of this? Maybe something involving a media-dependent stylesheet or something.
Yup. There's semi-official "hi-def" selector for CSS. Lots of sites are using it: http://www.netmagazine.com/tutorials/master-css-pixels-re...
Retina display support
Posted Jan 9, 2013 21:40 UTC (Wed) by roc (subscriber, #30627) [Link]
For non-Retina-aware apps, MacOS just scales the entire window up by a factor of 2. Being Retina-aware means for things we can scale intelligently (text, vector graphics) we do much better. For images we usually can't do much better although at least we give the author some control (choosing between nearest-neighbour and bilinear scaling via the image-rendering CSS property).
Retina display support
Posted Jan 10, 2013 9:52 UTC (Thu) by epa (subscriber, #39769) [Link]
Retina display support
Posted Jan 10, 2013 13:08 UTC (Thu) by nye (guest, #51576) [Link]
No, compared to showing it at the *expected* size. If my image is 800px wide, the expected size is 800px. Stretching it to 1600px mean showing it at *double* its expected size.
>On a Retina screen, images have to be scaled up somehow.
This is obviously the root of the disagreement, because I don't think that's true *at all*.
Why bother with a high density screen in the first place if you're not going to use it?
I have here a number of displays, ranging from around 100ppi to around 250ppi. Looking at the same image on the lowest and highest density displays, it looks far better on the higher one when displayed at its native size. If that gets rescaled to make it the same *physical* size, the theoretical best case scenario is that it looks like it does on the low density display, except in practice the better display means that you can really see the deficiency of the scaling.
I recognise that there is a real problem to be solved here, where some genius has specified a text height of 12px and some background image to match (or whatever), but the solution given doesn't seem like a good one at all.
Retina display support
Posted Jan 10, 2013 13:29 UTC (Thu) by nye (guest, #51576) [Link]
To be more specific, when looking at the same image at the same physical size and distance on both screens, the difference is that the high resolution display looks blurred - this is with whatever scaler the Android browser uses.
I *hate* blurry visuals. They're tiring to look at because my eyes keep trying harder to focus until they've had a *long* time to get used to the knowledge that they simply can't; that's something that never happens in the physical world, so it makes an unpleasant transition between looking at a screen and looking at real physical objects.
Related: the default font smoothing settings on Ubuntu (picked that only because it's the only distro I've used recently with an out-of-the-box config - maybe others are different) looks like somebody took a stick of lard and smeared it over the monitor; it disgusts me, and it's uncomfortable to read. In this area at least, high PPI displays are a clear win regardless of how images are treated.
I can see that the image-doubling behaviour would be desirable if you value large images over sharp images, but that's a position I can't even begin to empathise with in any way because my eyes find it physically unpleasant.
Retina display support
Posted Jan 12, 2013 6:55 UTC (Sat) by alankila (guest, #47141) [Link]
Interpolation filters produce errors when encountering high-frequency content of the image. These errors follow from ignored gamma correction (= scaled images tend to be too dark at high-frequency features) and modeling of image as infinitesimal points of specific color and intensity at particular points of a grid, rather than interpreting the image as an area-averaged sampling of an unknown light function. If you had a theory of the light function whose gridded area-average produced the current image, you would be able to resample such function to any resolution, and likely the results would be more natural too. In any case the upshot of the latter effect is reduction of contrast of high-frequency images. I studied the problem slightly here:
https://bel.fi/alankila/scaling/
Much more work should be done to turn this into something practical, though.
Retina display support
Posted Jan 12, 2013 19:02 UTC (Sat) by jimparis (guest, #38647) [Link]
There's a really simple light function that produces the current image: solid colored squares, each exactly the size of the image's pixels. Which leads exactly to the "pixel-doubling scaling" you describe. You might manage to come up with an alternate light function that also fits, but there's no way of knowing that it's any more correct.
Retina display support
Posted Jan 13, 2013 0:22 UTC (Sun) by alankila (guest, #47141) [Link]
So it is my faith that we can do better than that, and not even try very hard; the trouble may be in the corner cases where it would appear that we do worse. For instance, over/undersaturation is a risk for edge enhancements that are somehow tangentially involved in algorithm like this. How would you represent color that has negative luminosity? You can't, so for some cases the algorithm would have to degrade naturally.
Retina display support
Posted Jan 14, 2013 7:59 UTC (Mon) by ekj (guest, #1524) [Link]
But we don't know that, generally speaking. (though we can attempt to detect it) Lots of images are the result of computation, they might be output from a graphing-library, for example.
What works well for a photo of a face, doesn't always work well for output from gnuplot.
Retina display support
Posted Jan 10, 2013 13:34 UTC (Thu) by mpr22 (subscriber, #60784) [Link]
Rendering at 1px=1px on high-pixel-density high-pixel-count displays does not, on first inspection, look like it is likely to perform well on accessibility criteria. Converting a CSS distance of 1px into a display distance of two pixels looks rather more likely to perform well on this score. As long as those who crave tiny images can easily turn off the scaling, the default behaviour should be chosen to be kinder to those for whom tiny images are not sensible.
Retina display support
Posted Jan 9, 2013 22:26 UTC (Wed) by redden0t8 (guest, #72783) [Link]
Even if all the browser did was plain pixel-doubling, you'd still end up with your image exactly as it would appear on a low-dpi monitor - the only reason it looks worse is because the rest of the screen is high res so the pixelation is more obvious.
Once you add in good anti-aliasing, IMHO even a low-dpi image scaled up on a hi-dpi display looks better than the same low-dpi image displayed natively on a low-dpi display.
Retina display support
Posted Jan 9, 2013 11:39 UTC (Wed) by ewan (subscriber, #5533) [Link]
Retina display support
Posted Jan 9, 2013 12:53 UTC (Wed) by roc (subscriber, #30627) [Link]
Retina display support
Posted Jan 9, 2013 12:16 UTC (Wed) by niner (subscriber, #26151) [Link]
Retina display support
Posted Jan 9, 2013 12:34 UTC (Wed) by NAR (subscriber, #1313) [Link]
Retina display support
Posted Jan 12, 2013 16:14 UTC (Sat) by intgr (subscriber, #39733) [Link]
Retina display support
Posted Jan 14, 2013 10:38 UTC (Mon) by NAR (subscriber, #1313) [Link]
Retina display support
Posted Jan 21, 2013 23:30 UTC (Mon) by oak (guest, #2786) [Link]
Retina display support
Posted Jan 9, 2013 12:56 UTC (Wed) by roc (subscriber, #30627) [Link]
Retina display support
Posted Jan 9, 2013 13:18 UTC (Wed) by robert_s (subscriber, #42402) [Link]
_What_
"They were never defined to be screen pixels. The new Firefox behavior is completely consistent with the spec."
Thing is, they _have_ effectively been screen pixels for the last ~20 years, and that's how people have been using them.
Being able to describe things in terms of screen pixels is fairly critical in order to avoid fuzzy graphics.
Retina display support
Posted Jan 9, 2013 13:35 UTC (Wed) by Kit (guest, #55925) [Link]
I wouldn't be surprised if it hadn't been true in practice even before that.
Retina display support
Posted Jan 9, 2013 13:36 UTC (Wed) by roc (subscriber, #30627) [Link]
We've found ways to avoid almost all problems when zooming Web pages.
Retina display support
Posted Jan 9, 2013 15:02 UTC (Wed) by robert_s (subscriber, #42402) [Link]
Depends what you mean by reliably. I'd say it's a good 90% of the time people aren't zooming or using a mobile browser and they do correspond. And in a world where nearly half of visitors use IE so nothing really works properly anyway, I call that relatively reliable.
I'm just quite depressed by the whole way "retina" has been handled by everyone. There have been many efforts at resolution independence over the last ten years - now when significantly different resolution devices come into the market all that seems to have been thrown out the window and everyone seems to need to go round adding "retina"-specific hacks, "retina"-specific icons and whatnot to everything under the sun.
"We've found ways to avoid almost all problems when zooming Web pages."
As a web developer I look at that statement with eyebrows askew.
Retina display support
Posted Jan 9, 2013 15:40 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Retina displays allow no such slack. So everyone suddenly realized that their code is not actually that resolution independent and they have to do something about it.
Retina display support
Posted Jan 9, 2013 18:59 UTC (Wed) by redden0t8 (guest, #72783) [Link]
The browser still lays things out identically, it just renders extra pixels for text+vector graphics, and anti-aliases raster images. That's the whole reason why it's implemented using a pixel-ratio. Everything automatically works.
Coding webpages in real units is impractical anyways, as you don't know the device it'll be displayed on. No one on a phone wants a webpage to be initially zoomed to be 10 inches wide when their screen is only 2-3 inches wide. The first thing they'll do is zoom out to figure out where to scroll to before zooming back in. Same idea for a tablet. Laptops/desktops are a little easier, but you still don't know the size of the display (9" netbook or 30" desktop?), how far away the user is sitting (HTPC or netbook?), and how good their eyesight is. Ultimately, it's up to the device-maker and end user.
All the web-developer needs is a reference unit. The "pixel", while poorly named, already provides this. Each device maker can decide how to handle the scaling ratio for a given form-factor. Ideally one day, once desktop OS's are truly resolution independent, they'll let end-users pick their "ideal" ratio with a slider somewhere that affects the entire UI.
Yes you'll need to start serving up higher resolution images soon or later, but this is caused by hi-dpi displays in general and not just Retina(TM) displays. It's already possible to query the device pixel ratio in a browser-independent way, or alternately blindly serve up high-res images to everyone.
Retina display support
Posted Jan 9, 2013 20:09 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
I've actually long wished that we had some kind of 'pixels' with fixed angular size. But I kinda doubt that most web-developers would like to work with steradians :)
Retina display support
Posted Jan 9, 2013 21:41 UTC (Wed) by roc (subscriber, #30627) [Link]
Retina display support
Posted Jan 9, 2013 21:59 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
That's not a problem right now, since browser does all the drawing. But once we move into the brave new Canvas world, we'll start to get this kinds of problems. 1 pixel on a Retina display might be below eye's resolution, but 1px misalignment is easily noticeable.
Retina display support
Posted Jan 10, 2013 10:35 UTC (Thu) by roc (subscriber, #30627) [Link]
Retina display support
Posted Jan 11, 2013 10:02 UTC (Fri) by jezuch (subscriber, #52988) [Link]
Retina display support
Posted Jan 13, 2013 11:01 UTC (Sun) by jospoortvliet (guest, #33164) [Link]
Retina display support
Posted Jan 9, 2013 16:08 UTC (Wed) by niner (subscriber, #26151) [Link]
"For a CSS device, these dimensions are either anchored (i) by relating the physical units to their physical measurements, or (ii) by relating the pixel unit to the reference pixel. For print media and similar high-resolution devices, the anchor unit should be one of the standard physical units (inches, centimeters, etc). For lower-resolution devices, and devices with unusual viewing distances, it is recommended instead that the anchor unit be the pixel unit."
So for example a 3rd generation Apple iPad with so called "Retina display" has a screen resolution of 263.92 PPI which is much closer to a 300 DPI print than to the usual 90 DPI of a computer screen. Google Nexus 10 features 300.24 PPI. So I would say these devices are what the spec call "print media and similiar high-resolution devices" and 1px sould be 0.75pt or 0.26458333mm.
Using 2x2 device pixels seems to be just as wrong as using 1x1. 2 display pixels on the Nexus 10 for example are just 0.1692mm wide compared to ~ 0.26mm width of the reference pixel the CSS spec uses.
Retina display support
Posted Jan 9, 2013 21:39 UTC (Wed) by butlerm (subscriber, #13312) [Link]
As a result, 2 x 2 device pixels per CSS pixel is just about ideal for a 192 DPI desktop display. Ideal as in minimizes aliasing for pixel oriented page designs, which are commonplace. If you have a handheld device, the DPI should be higher because the viewing distance is going to be less. 384 or even 400 dpi sounds about right for 2 x 2 scaling (2 dppx) on a device like that. 4x4 scaling someday (~768 DPI handheld, 384 DPI desktop) sounds well within the retina limit to me, at least if you want to avoid eyestrain.
Retina display support
Posted Jan 9, 2013 21:45 UTC (Wed) by roc (subscriber, #30627) [Link]
Retina display support
Posted Jan 10, 2013 2:09 UTC (Thu) by Trelane (subscriber, #56877) [Link]
What are you looking for exactly?
xrandr --query
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
LVDS1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 345mm x 194mm
1920x1080 59.9*+
1400x1050 60.0
1280x1024 60.0
1280x960 60.0
1024x768 60.0
800x600 60.3 56.2
640x480 59.9
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
is this what you need (modulo actually having to run xrandr instead)?
http://developer.gnome.org/gdk3/stable/GdkScreen.html
perhaps?
Retina display support
Posted Jan 10, 2013 10:36 UTC (Thu) by roc (subscriber, #30627) [Link]
Retina display support
Posted Jan 11, 2013 1:09 UTC (Fri) by FedericoMenaQuintero (guest, #81416) [Link]
(Your controls *will* be the same size as those in other applications, because you are using the same toolkit.)
Firefox 18 is now available
Posted Jan 9, 2013 14:39 UTC (Wed) by mirabilos (subscriber, #84359) [Link]
Firefox 18 is now available
Posted Jan 9, 2013 16:38 UTC (Wed) by dskoll (subscriber, #1630) [Link]
Runs fine for me on Squeeze 64-bit. Posting from FFox 18 now.
Firefox 18 is now available
Posted Jan 9, 2013 18:28 UTC (Wed) by iarenaza (subscriber, #4812) [Link]
Firefox 18 is now available
Posted Jan 9, 2013 18:38 UTC (Wed) by nteon (subscriber, #53899) [Link]
Firefox 18 is now available
Posted Jan 10, 2013 10:14 UTC (Thu) by khim (subscriber, #9252) [Link]
"newer feature" is overstatement. Most likely this is the result of the old tempest: when GLibC developers changed memcpy to copy things from the end (it's faster on some CPUs for some obscure reasons) they found out that it broke few programs (Flash is the most important one).
Programs are incorrect (since memcpy was never promised to be usable with overlapping src and dst), but they are popular and that's why GLibC 2.14 has two versions of memcpy: memcpy@GLIBC2.2 and memcpy@GLIBC2.14. This basically means that more-or-less any program compiled with GLibC 2.14 is not usable with older versions of GLibC. Note that this difference only exist in x86-64 version of GLibC, 32-bit version does not have new optimized memcpy!
Firefox 18 is now available
Posted Jan 10, 2013 19:42 UTC (Thu) by mirabilos (subscriber, #84359) [Link]
https://bugzilla.mozilla.org/show_bug.cgi?id=723487 is the bugreport.