Can anyone with a retina display and the Firefox nightly check this test case for Canvas, please: http://www.phoboslab.org/crap/backingstore/

I hope they didn't screw it up as bad as Apple did with Safari: http://www.phoboslab.org/log/2012/09/drawing-pixels-is-hard

Edit: judging from some comments in the source, the Canvas element still uses a low resolution, so the test case should work as expected in any case.

I just tested this and unfortunately the test case doesn't pass on the nightly. I am seeing (252,40,252) instead of the (255,0,255).

Same here:

(0,0,0),(252,40,252),(0,0,0),(252,40,252),(0,0,0),(252,40,252),(0,0,0),(252,40,252), (252,40,252),(0,0,0),(252,40,252),(0,0,0),(252,40,252),(0,0,0),(252,40,252),(0,0,0), (0,0,0),(252,40,252),(0,0,0),(252,40,252),(0,0,0),(252,40,252),(0,0,0),(252,40,252), (252,40,252),(0,0,0),(252,40,252),(0,0,0),(252,40,252),(0,0,0),(252,40,252),(0,0,0), (0,0,0),(252,40,252),(0,0,0),(252,40,252),(0,0,0),(252,40,252),(0,0,0),(252,40,252), (252,40,252),(0,0,0),(252,40,252),(0,0,0),(252,40,252),(0,0,0),(252,40,252),(0,0,0), (0,0,0),(252,40,252),(0,0,0),(252,40,252),(0,0,0),(252,40,252),(0,0,0),(252,40,252), (252,40,252),(0,0,0),(252,40,252),(0,0,0),(252,40,252),(0,0,0),(252,40,252),(0,0,0),

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/18.0 Firefox/18.0 as downloaded and installed just a few minutes ago.

Doesn't work in Firefox on Windows either, so maybe the test case is just broken? I see (0,0,0),(212,52,248)

Retina support is not in Nightly yet. But very very soon (if not today, tomorrow).

I wonder at what kind of resolution we will no longer need anti-aliasing. Did they provide any Retina screenshots with AA off? You'd think that with small enough of a pixel it would no longer be necessary.

There is no clear cut answer to that. Even at 10,000ppi you can still get visual artifacts without anti-aliasing. The problem is pixles are averaging a single point source over a 'full' pixel so with some patterns they can become vary sensitive to slight motions. Think chain link fence, all the pixels could be on the fence and it looks solid, or between them and it looks clear, and if your rotation it can swap between them.

Not there yet. I turned off AA in the Terminal and it looks smooth, but not completely. If I use a lower scaled resolution like 1440x900, then it looks even smoother, but again not completely smooth. So I guess an even higher dpi is needed. It would be interesting to see non-antialiased fonts on the iPhone which has a much higher dpi.

I think I managed to downvote you by mistake. Sorry…

What is there in a higher-resolution display that actually needs software support from Mozilla?

Applications need to be 'retina aware' to actually get the full resolution, otherwise they are told the resolution is 1440x900 (this doesn't include fonts, and other system-rendered features, which the OS can always render at full resolution). The program icons also need to be shipped in a higher resolution.

More pixels..? Apps that aren't updated are pixel doubled, so images, and in some cases text, are jaggy and blurry until they're updated.

I'm not sure, but the entire application looks pixelated and blurry, like it's rendered at half-size and scaled up. It's really bizarre.

Apple does something called pixel doubling. If an application takes no action, it won't just be rendered smaller. Instead, Apple zooms the whole app, causing everything to get very fuzzy.

OT: When does HN upgrade it's voting arrows for Retina displays?

Preferably it would be CSS.

   .upArrow {
   width: 0; 
   height: 0; 
   border-left: 6px solid transparent;
   border-right: 6px solid transparent;
   border-bottom: 6px solid #828282;
   }

CSS is fine with me. On the desktop, we could even replace the non-Retina arrows with own CSS and images, however, Safari on iOS doesn't offer this possibility.

So do Retina apps mean we now have to deal with larger software packages, even if we don't have retina displays?

I guess so, same as on iOS devices. The example of iOS, however, shows that Retina will become the standard sooner or later … :)

I'm confused about this. I've been running the sept 11 Nightly and it has retina support. Did they take it out, and this is just about re-adding it?

Prior to that I used the "retinizer" app and the about:config hack to disable acceleration, but performance was really bad. Since running nightly, it has been fully retina enabled and smooth.

About frickin' time. Firefox looks horrible on retina Macbooks right now, to the point that it's unusable.

Relative term, and totally subjective. I have an rMBP, and use Firefox (as well as InDesign) all the time, and it's not horrible. If your entire screen looked that way, you wouldn't even notice.

Maybe yours does something that mine doesn't, but here's a screenshot: http://cl.ly/image/2O2K1g411N3l/Screen%20Shot%202012-09-29%2...

Left is Firefox, right is Chrome. Nothing special done to either. MBP is at the factory resolution. Very ironically, the screenshot at half-size looks better on my 24" Windows display than it does on the actual MBP does, presumably as Chrome is doing some resampling to downsize it. Look at it at full zoom to see what I mean.

I'm doing active web development on a number of browsers across a number of devices (Macs, Windows, iOS, Android), and Firefox on the Mac is easily the worst of the lot, by a rather large margin. I would easily notice if the whole screen looked like it - text is blurry and awfully aliased, to the point that it's jarring to read. I spend most of my time on Windows, which by most accounts has less beautiful text rendering than OS X, and switching over to Firefox on the rMBP feels just awful.

Given that I spend 99% of my day looking at a 94 DPI screen, I don't think it's too much to ask that the same application on my 220 DPI display not look like I'm playing Minecraft.

For me both windows look almost the same. And definitely Firefox is not "unusable" from this single screenshot.

Could you write more what is wrong with firefox on this screenshot?

The text is fuzzy and blurry. You may not see it if you don't zoom in (to 100%), because your browser will apply crappy resizing filters to the whole image, so both browsers will have the same look.

I don't even see what you're referring to. The corners on Firefox have a slightly less subtle curve, I guess...

I don't know if you're being hyperbolic, but that feels like a really minor thing to me.

Is this better? http://i.imgur.com/qiZgj.png

Direct comparison of some of the more egregious examples in Firefox (Top) vs Chrome (bottom). Look at the tab title, the text in the dark grey nav bar, the aliasing on the back button, the aliasing on the text, the aliasing on the edge of the "O" in the Google logo, and the aliasing of the text under the buttons.

It's more obvious when zoomed in and I can see your point. But do you not experience the first image, the zoomed out version? In that one I can barely differentiate.

No; oddly enough, the scaled-down image looks better than the actual rMPB does! This makes zero sense to me, but it is what it is.

It's pixel-doubled like every other non-native-Retina app on your Mac. Why is it Firefox's problem if Apple didn't bother to go to the trouble of making non-Retina applications readable on a Retina display? The fact that they don't even bother to do filtering when pixel doubling is probably a big contributor to readability issues (note that Vista and W7 do filtering when doing DPI adjustment, likely for this exact reason), not to mention the fact that it appears to be doing subpixel antialiasing when there are no subpixels to address (WTF, Apple?)

> Why is it Firefox's problem if Apple didn't bother to go to the trouble of making non-Retina applications readable on a Retina display?

I'm not sure what they could have done beyond making sure Cocoa's text-rendering routines produce the right "retina" output. Which they do. Firefox (and Chrome) do their own text rendering and rasterizing, as far as OSX can see it they give it a big image to display. Not much OSX can do with that.

they could have not pixel doubled the applications and instead let them be smaller and still crisp.

Crisp is not very useful when you can't read the text or view the pictures because they're a quarter of their "intended" physical size.

This is fabulous, now if I could get it for the iPad, tell it to lie about what kind of device I was so that I would not be stuck with the 'mobile' version of Gmail. That would be a usability win.

Gmail's mobile version has links at the bottom: 'View Gmail in: Mobile | Older version | desktop'

Why do you need "support" for a screen resolution? PC's have had different screen resolutions forever, why were there never news articles about "Firefox Gets Support For 1280x1024" or "Firefox Gets Support For 1920x1200"?

1920x1200 does not equal high dpi. Think 1920x1200 on a 10" display. If your app runs on a high DPI screen, and the OS and your app has no support for this, all fonts and UI elements become tiny, which is unacceptable.

Windows XP had abysmal support for high DPI which usually resulted in broken UI layout. Vista introduced "DPI virtualization" requiring you to declare and provide explicit support for variable dpi in your application. Otherwise it is run at 96 DPI and raster scaling is applied. This prevents any UI layout issues but results in a a blurry image. I guess Apple uses the same approach: if your app has no explicit support, it runs under raster scaling.

yeah, no. Just downloaded it.

http://i.imgur.com/pbGvv.png

whole thing looks like this.

That's because it's not in today's (Sept 29) build yet. It'll be in tomorrow's build.

Today's nightly: http://hg.mozilla.org/mozilla-central/rev/c09a0c022b2e

Last retina changeset: https://hg.mozilla.org/mozilla-central/rev/1d3de8da2508

Shortlog: https://hg.mozilla.org/mozilla-central/shortlog

Has it been fully implemented? The bug says that it's resolved.

https://bugzilla.mozilla.org/show_bug.cgi?id=674373

In Mozilla's bug workflow, RESOLVED FIXED means the fix has been checked into Firefox's Mercurial trunk (the "mozilla-central" branch), but the fix won't be available for testing until the next Nightly build. VERIFIED FIXED means QA has tested the Nightly build and confirmed the bug has been fixed.

Firefox is at v18? Last I knew it was at v5. Guess they didn't waste any time in their quest to catch up with Chrome.

No, Firefox is at v15. v16 will be released on Oct 9th. Personally, I just run the Nightly (http://nightly.mozilla.org/) and get an update every day. It's simply "today's build."

The version number is meaningless. What is meaningful, however, is getting millions of people to help test beta browsers. If Chrome is your browser of choice then help test the Canary builds (https://tools.google.com/dlpage/chromesxs)

That joke never gets old, let's keep saying it every time a Chrome or Firefox version comes out! (Or like here, just because a Chrome or Firefox version number was mentioned in a random article.)

Joke aside, this whole rapid release thing is irritating when it requires me to restart my browser all the time.

You would otherwise restart your browser less frequently than every six weeks?

No browser AFAIK has the ability to patch a running process (it's very hard to do in general, but there are some ways to do it to a linux kernel for example). So you must restart to actually run the downloaded updates. Which means until you restart, you are running an unpatched browser which might have known exploits.

If each tab is a separate process, they could be upgraded one by one. You could even signal to each tab that it should open all links in a new process. Browsers are probably the app you could most easily transparently upgrade.

Not correct. Multiprocess browsers like Chrome don't actually run an entire browser in each process (that isn't realistically possible) because the individual tabs need to collaborate for the proper functioning of things like caches, cookies, etc.

If. If I can restart a web server without restarting memcache and have a new process handle new requests while the old process handles existing requests, it's clearly possible for a browser to change its rendering engine for new tabs.

The rendering engine, sure, but what about the rest of the browser? Cache, Cookie, Prefs, bookmarks, etc.

Browsers are not just rendering engines.

It's possible in theory, but very hard. None do it to my knowledge.

Pretty sure silent updates got rolled out around v15.

On Ubuntu, Chrome and FF updates are pushed through the repos and are updated through apt-get / Update Manager. It's not annoying at all, and works like clockwork. Kudos to Chrome, FF and Ubuntu!

On Windows, Chrome does a good job auto update in the background. Firefox am not so sure but they too are working on some kind of auto update. Good for them, not being stubborn, and implementing a good feature that their rival has.

Good for Chrome that they aren't suing others trying to implement auto update. :-)

"All the time" == "Once every six weeks"