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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
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. :-)
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.