When running in HiDPI mode on OS X Lion, we should show double size icons, and make sure that the text is rendered properly.

What happens currently? I know we consider the screen's DPI, though I think we don't start adjusting for it until after some threshold (though aiui HiDPI is 2x the usual setting, so I'd assume that's enough to do it...)

I think we should start here by implementing nsChildView::GetDefaultScale() to return something other than 1.0 when appropriate.

I should add that, funnily enough, Firefox, up to version 3.6.21, renders the fonts on webpages correctly under HiDPI. Starting with Firefox 4.0 UI fonts, and the fonts on webpages, are very pixelated under HiDPI. The same is true for Thunderbird: UI fonts, and the fonts in email messages, render correctly only until Thunderbird version 3.1.11, and not in subsequent versions.

This screenshot was taken on a HiDPI display (IBM T221) on OS X 10.7.3, on the left is Firefox 10.0.1, on the right you see Safari 5.1.3. Safari looks absolutely stunning at 204 dpi. With the advent of HiDPI Macbooks it would be great if Firefox were ready for it.

Yup, we tested this with Air Display earlier today too, it looks like this: http://f.cl.ly/items/2z372F1l0H0o092a3M05/Screen%20Shot%202012-04-02%20at%204.03.20%20PM.png Markus, do you have any idea why the window decorations are low-res even when running in HiDPI? I assume we copy them from the lower-res version since we want to support themes in the titlebar. That we don't render fonts at the native resolution is interesting too.

(In reply to Alex Limi (:limi) — Firefox UX Team from comment #5) > Markus, do you have any idea why the window decorations are low-res even > when running in HiDPI? I haven't looked at this at all yet, but maybe there's a per-application switch that we need to flip before OS X gives us HiDPI window decorations.

Note, 10.7.3 will show HiDPI modes if you are plugged into a HDTV via HDMI. I use 960x540 HIDPI exclusively. This works much better than using a blurry 720p mode on a 1080p display just to get a UI that's usable at a distance. Now if only I could use Firefox instead of just Safari. I don't think this is a feature you should wait on adding. Not only useful for TVs but also for people with poor vision.

If the rumours are correct, Apple may be releasing HiDPI computers in June. I think we should at least render all widgets and cursors at 4x resolution and get them pushed. Just so we are most the are ready for when and not if Apple announce HiDPI. It will look good for Mozilla if they're one of the first third party developers to support HiDPI. Is there any API switch to tell the OS that the app is HiDPI supported in OS X Lion?

Through much trial and error I've found out that the NSPrincipalClass key needs to be present in our app bundle's Info.plist file, otherwise HiDPI support is turned off. I wouldn't call that an API, but at least now we know how to enter HiDPI mode at all. Googling "HiDPI NSPrincipalClass" tells me that the Chrome guys had the same problem: http://codereview.chromium.org/10069029

With this patch, at least the window decorations are high resolution now. With hardware acceleration off, font and border rendering is already high resolution, too.

Patch doesn't work for me; window decorations etc remain pixelated.

In comment #7 HIDPI Fan mentions one way to test HiDPI mode. Are there others? I need detailed steps! :-)

You can enable HiDPI resolutions using 'Quartz Debug' in Xcode 4.1 on 10.7.3. Select 'Window->UI Resolution'. In my computers the setting was checked so I had to disable, logout, enable, logout. After this HiDPI resolutions appear in System Preferences. I believe this will simulate HiDPI displays for development. Currently unpatched we run severely pixelated.

Here's another screenshot of (unpatched) Firefox and Safari in HiDPI mode, in which I'd say that they look equally pixelated. (You have to zoom in on the image to see this.) This was on a non-Apple monitor (an NEC LCD2190UXp display) -- which may explain the difference from Benoit's test. I used Grab to take the screenshot, and Preview to convert it to PNG.

(Following up comment #15) I tested on OS X 10.7.4.

I don't think that you are running the same HiDPI mode as I was. Note that the top right 'full screen' button is 15x15 on your screenshot and 30x30 on mine.

Oops, now I see my mistake. I did test in what OS X told me was a genuine 800x600 HiDPI mode. But it was on a second monitor attached to my MacBook Pro, while my MacBook Pro's display was in a non-HiDPI mode. When I set both displays to NiDPI mode, I can see a difference between Firefox and Safari -- Firefox is more pixelated.

Here's a screen shot of FF 13 in 800x600 HiDPI mode, "patched" (on the left) and "unpatched" (on the right). I can't detect any difference in pixelation between the two -- both seem more pixelated than Safari. To achieve the effect of Markus' patch, I just changed the Info.plist of one copy of FF 13. The only difference I can detect between the two (which doesn't show up in a screenshot) is that menu text is less pixelated with Markus' patch than without. This is presumably because the menus are actually native objects (unlike everything else in Firefox's UI).

> The only difference I can detect between the two (which doesn't show > up in a screenshot) is that menu text is less pixelated with Markus' > patch than without. It's hard to tell, but the menu icons seem equally pixelated. Which makes sense considering neither "version" of FF 13 has high-resolution bitmaps in the images corresponding to the menu icons.

Here are some docs that seem relevant: http://developer.apple.com/library/mac/#releasenotes/GraphicsAnimation/RN-HiDPI/_index.html https://developer.apple.com/library/mac/#releasenotes/Cocoa/AppKit.html Search on "HiDPI" in the latter.

More docs: https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/HiDPIOverview/HiDPIConcepts/HiDPIConcepts.html http://developer.apple.com/library/mac/#samplecode/CocoaTipsAndTricks/Listings/BlurryView_BlurryViewAppDelegate_h.html#//apple_ref/doc/uid/DTS40010039-BlurryView_BlurryViewAppDelegate_h

(In reply to comment #3) I'm not able to reproduce what you report. I tried with both FF 3.6.21 and 3.6.19, using this bugzilla page and the stardard 3.6.X startup page. In both cases the fonts were just as pixelated as with later FF versions, and quite a bit more pixelated than the same pages in Safari. Do you mean anything special (specific) by "fonts on webpages"? Were you using any non-default settings that might have made a difference? (It's been a long time since your comment, Andre. But I hope you're still listening here.)

(Following up comment #19) > The only difference I can detect between the two (which doesn't show > up in a screenshot) is that menu text is less pixelated with Markus' > patch than without. This turns out to be true only of context menus. Text in the main menu is non-pixelated (or no more pixelated than in Safari) even without Markus' patch.

(In reply to comment #2) > I think we should start here by implementing > nsChildView::GetDefaultScale() to return something other than 1.0 > when appropriate. This doesn't work. I tried doing this unconditionally (and also setting layout.css.devPixelsPerPx to -1.0). But all it does is make every object twice as wide and twice as high, even in a HiDPI display mode. Moreover, fonts and graphics are just as pixelated, and are more pixelated than they are in Safari if you zoom Safari to the same dimensions. (Many (most?) graphics on web pages don't look better in Safari than in Firefox -- presumably because they don't have sufficiently high-resolution bitmaps. But the zebras currently on Apple's home page (in the ad for the new MacBook with a Retina display) do have a high enough resolution bitmap, and do look better in Safari.)

For those who are curious: I tried making FF use ATS fonts on all versions of OS X (by making gfxMacPlatformFontList::UseATSFontEntry() always return true). This didn't make any difference -- our fonts are still just as pixelated in a HiDPI display mode. (Normally we use the CGFont/CTFont APIs on OS X 10.6 and up, because the ATS fonts are so buggy. See bug 663688.)

(In reply to Steven Michaud from comment #19) > The only difference I can detect between the two (which doesn't show up in a > screenshot) is that menu text is less pixelated with Markus' patch than > without. This is presumably because the menus are actually native objects > (unlike everything else in Firefox's UI). We should consider uplifting simple patches like this if the risk is judged low enough. Get some low hanging fruits released ASAP.

Comment on attachment 624738 [details] [diff] [review] add NSPrincipalClass entry > We should consider uplifting simple patches like this if the risk is > judged low enough. Get some low hanging fruits released ASAP. I agree. Though this patch does almost nothing by itself, it's probably a prerequisite for doing anything else. I can't think of any way in which this patch would cause harm, so I'm r+ing it. Markus, are you able to land your patch, or should someone else do it for you?

I'm not able to, please land it for me.

> I'm not able to, please land it for me. Will do.

Comment on attachment 624738 [details] [diff] [review] add NSPrincipalClass entry Landed on mozilla-inbound: http://hg.mozilla.org/integration/mozilla-inbound/rev/c56ea8815618 Whoever lands this, please don't mark this bug fixed. Our work has only just begun :-(

Blocking/related to bug 378927 and bug 348059?

(In reply to Steven Michaud from comment #31) > Whoever lands this, please don't mark this bug fixed. Our work has only > just begun :-(

Apologies for the incorrect resolution - testing a semi-automated tool for post-merge bug marking, so our sheriffs don't have to spend hours manually resolving 100+ bugs. It looks for [leave open] in the whiteboard, per https://wiki.mozilla.org/Inbound_Sheriff_Duty, and won't resolve such bugs.

Just to add to comment 35, humans currently look for that whiteboard annotation too, so this would have been inadvertently closed either way.

> http://developer.apple.com/library/mac/#releasenotes/GraphicsAnimation/RN-HiDPI/_index.html This seems to have disappeared, and (possibly) been replaced by: http://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Introduction/Introduction.html

I'm going to put this bug aside for a while and work on other, more urgent bugs. It'll probably be several weeks before I can get back to it.

(In reply to comment #32) > Blocking/related to bug 378927 and bug 348059? Not really (though all three bugs are about the same general problem). The reason is that this bug is Mac-specific and HiDPI-specific, and fixing it probably won't require any changes to cross-platform code. (In fact, as you can see from comment #25, plausible changes to cross-platform code may actually cause harm.)

> fixing it probably won't require any changes to cross-platform code Aside from the need to create higher-resolution bitmaps for our browser chrome.

Fingers crossed this bug is completed before 2015.

What optimism Mil. Are all the assets as vectors online anywhere? Get the community to make hires versions. Mozilla are already over a year behind getting a lot of OS X features in release versions (full screen as an example). My experience is people are dumping Firefox on the Mac because Mozilla are not progressing quick enough for the platform.

>If the “Open in Low Resolution” checkbox is selected by default for your >app—whether >the checkbox is available (dimmed) or not—you can change the >default by: > > - Fixing all bugs related to high resolution > > - Setting the NSHighResolutionCapable attribute to YES, in the Info.plist > for the app, as shown in Figure 1-8. From: http://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html

We're really missing out on a lot of free marketing here. Apple community is lapping up Chrome offering retina support http://chrome.blogspot.co.uk/2012/06/chrome-and-new-shiny.html

My Retina-display MacBook Pro arrived this morning; I've made a fresh build of Firefox and can confirm that on this machine, in HiDPI mode, I see high-resolution window decorations and pop-up menus. The rest of visible content remains low-resolution, but we aren't being forced down the whole-app pixel-doubling path. Yay!

Brion, you post some screenshots? And what do you mean by "a fresh build". Did you make any code changes? Are your results with your "fresh build" better than with (say) today's mozilla-central nightly? If so, please also post some screenshots from the nightly for comparison. > I see high-resolution window decorations and pop-up menus I already knew about the pop-up menus (with Markus' patch). But in my own tests I haven't seen any improvements in "window decorations". So please be more precise what you mean by that phrase. Also note that in my own tests, it's our text (our fonts) that look worst in HiDPI mode. Have you found any way to fix that?

My build is against changeset: 96792:4e3362864fbd Behavior seems about the same as current download at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-16.0a1.en-US.mac.dmg Screenshot was taken with no code changes. * window decorations (close/minimize/maximize buttons and the corners of the windows) show high-res * AwesomeBar drop-down text shows high-res * everything else is low-res If I go into about:config and set "layers.acceleration.disabled" to true, then text looks beautifully high-resolution, as do the thumbnails on the new tab page. (will post screens) I also tried making a slight change to nsCocoaWindow.GetDPI to call [aWindow backingScaleFactor] instead of [aWindow userSpaceScaleFactor] to remove a deprecation warning, but it appears not to make any effect itself (I still get high-res text if layers acceleration is disabled, with or without this change).

Currently nightly build (unmodified), with "layers.acceleration.disabled" to true via about:config. With acceleration disabled, fonts render in very nice high resolution.

> If I go into about:config and set "layers.acceleration.disabled" to > true, then text looks beautifully high-resolution, as do the > thumbnails on the new tab page. Very interesting. Thanks for finding this out, and letting us know. We can't turn off layers acceleration. But knowing that this setting makes a difference gives us a much better idea where we'll need to make changes.

(In reply to Steven Michaud from comment #49) > We can't turn off layers acceleration. But knowing that this setting > makes a difference gives us a much better idea where we'll need to > make changes. Indeed, if I had access to the hardware my first attempt would be poke in LayerManagerOGL and see if we're compositing a 1:1 or 2:1 with hardware acceleration. If it's 1:1 then we likely have to tweak CoreGraphics, if not we have to tweak nsChildView widget and the layer manager.

I'll be more than happy to run any exploratory test patches you guys can devise.

By they way, the powers that be have changed their minds about how urgent they think this bug is. So I'll get started on it next week. With luck the same powers that be will be giving me a new Retina MBP :-) The first thing I need to do is work more carefully through the various docs I've found. But thanks for your suggestion, Benoit. I'll definitely keep it in mind.

Hi Stevan, you might already know this, but existing (non-Retina) Mac users can enable and test HiDPI mode with these steps: 1. Download Graph Tools for Xcode (includes Quartz Debug) from Xcode > Open Developer Tool > More Developer Tools... menu in Xcode 4.3, or download it from http://developer.apple.com/downloads directly. 2. Launch Quartz Debug. 3. Choose Window » UI Resolution and enable "HiDPI". 4. Log out and re-login to activate the change. Aftewards, the Displays preference in System Preferences will now have '(HiDPI)' appended to their name. As a data point, I'm currently writing this comment in "720x450 (HiDPI)" mode in a late-2008 MacBook Pro with Firefox Nightly, and indeed the layers.acceleration.disabled setting made all the difference -- Thank you Benoit!

Related bug 765914: -moz-device-pixel-ratio reports as 1.0 when running on HiDPI screen. Until that's fixed we can't target high-resolution images in stylesheets. (Firefox's chrome styles may need the same thing fixed to implement loading of appropriate assets.)

(In reply to Steven Michaud from comment #49) > > If I go into about:config and set "layers.acceleration.disabled" to > > true, then text looks beautifully high-resolution, as do the > > thumbnails on the new tab page. > Changing this setting in 13.0.1 on the MacBook Pro with Retina display has no effect for me. It may only affect the display when simulating HiDPI.

(In reply to Harvey Chapman from comment #55) > > > If I go into about:config and set "layers.acceleration.disabled" to > > > true, then text looks beautifully high-resolution, as do the > > > thumbnails on the new tab page. > > > > Changing this setting in 13.0.1 on the MacBook Pro with Retina display has > no effect for me. It may only affect the display when simulating HiDPI. That'll only work on a current nightly build (16.x) -- 13.x doesn't have the right goodies in the Info.plist and gets run in zoomed compatibility mode.

(In reply to Brion Vibber from comment #56) > That'll only work on a current nightly build (16.x) -- 13.x doesn't have the > right goodies in the Info.plist and gets run in zoomed compatibility mode. Ah, confirmed. I downloaded the latest nightly and with that setting, the text looks crisp.

A fix here will probably involve returning the correct number from nsIWidget::GetDefaultScale(). By returning 2.0 we'll treat every CSS pixels as 2x2 device pixels. We will probably need to have something somewhere to ensure that window dimensions are all in device pixels and that our rendering isn't scaled up by 2 again.

(In reply to comment #58) Probably not. See comment #25.

That's probably because whatever already scales our output up by a factor of 2 keeps on doing so after we've added our own default scale. We need to opt out of whatever that is.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #60) > That's probably because whatever already scales our output up by a factor of > 2 keeps on doing so after we've added our own default scale. We need to opt > out of whatever that is. It's a transform that the CGContext we get in drawRect comes with. If we reverse that transform so that one user space point maps to one dev pixel again, things go right. The problem with that is that all units on nsIWidget APIs and friends (screen, screen manager, accessible) are expected to be in dev pixels, so in Cocoa-land we'd have to multiply all our Cocoa coordinates with the backingScaleFactor to get dev pixels. The other solution I see is to create a new fractional unit, say "screen points", that maps to the CGFloat points which the Apple docs want us to use everywhere, and use that for all screen pixel APIs. Then we'd have four coordinate units (app units, css pixels, dev pixels and screen points). I'm not sure which approach is worse. The screen point approach looks a little better in some places, for example when the UI resolution changes dynamically (which happens for example when a window is dragged from a non-HiDPI screen to a HiDPI screen): When that happens, the window's dev pixel size changes, so it'd not only fire a resolution change event, but also a resize event, even though its size doesn't really change. With the screen point approach, the window's screen point size would stay the same and it'd only fire a resolution change event. At first I thought there were more places that would cause problems with the dev pixel approach, for example double screen coordinates on DOM events, but those aren't a problem because those coordinates are in CSS pixels, not in dev pixels. I'll upload the patches that I have up to now, but unfortunately I can't justify spending any more time on this in the coming four to six weeks, so maybe Steven can drive them to conclusion.

This patch makes our native theme rendering work with HiDPI. It can be tested without running in HiDPI mode, just by setting the layout.css.devPixelsPerPx to 2.0 or by zooming normal web pages. Cocoa renders controls in high resolution if it detects an appropriate scale transform on the context we give it. In some cases we render controls into bitmap contexts first (see the hunks which have CGBitmapContextCreate in them), so for high resolution rendering we need to double the size of these bitmap contexts and set a scale transform on them. The rest of the patch ensures that native widgets rendered in zoomed pages are upscaled rather than extended at devpixel resolution. This is best explained with an example: If we have a multi-line text field on a webpage that is 400x300 pixels big, we'll render that with a one pixel border. If we now zoom that page to 2x, native theme rendering will render a 800x600 text field which still has a 1px border; as a result, the text field will look stretched rather than zoomed. This patch makes us render a 800x600 text field with 2px border instead, by pushing a 2x scale transform on the context and continuing with a size of 400x300 (which then gets scaled to the right size by the context). For that to work correctly, we also need to scale the results of GetWidgetBorder and GetMinimumWidgetSize.

(In reply to Markus Stange from comment #61) > It's a transform that the CGContext we get in drawRect comes with. If we > reverse that transform so that one user space point maps to one dev pixel > again, things go right. OK. > The problem with that is that all units on nsIWidget APIs and friends > (screen, screen manager, accessible) are expected to be in dev pixels, so in > Cocoa-land we'd have to multiply all our Cocoa coordinates with the > backingScaleFactor to get dev pixels. > The other solution I see is to create a new fractional unit, say "screen > points", that maps to the CGFloat points which the Apple docs want us to use > everywhere, and use that for all screen pixel APIs. Then we'd have four > coordinate units (app units, css pixels, dev pixels and screen points). > I'm not sure which approach is worse. The screen point approach looks a > little better in some places, for example when the UI resolution changes > dynamically (which happens for example when a window is dragged from a > non-HiDPI screen to a HiDPI screen): When that happens, the window's dev > pixel size changes, so it'd not only fire a resolution change event, but > also a resize event, even though its size doesn't really change. With the > screen point approach, the window's screen point size would stay the same > and it'd only fire a resolution change event. One problem with the "screen points" approach is that layout and gfx then aren't aware of what the true device pixels are, which will cause all kinds of problems. For example, all temporary bitmaps and surfaces (such as used by the GL compositor, for example, and our blurring code) will be the wrong size and cause unnecessary pixelation. Another example, CSS borders are rounded to the nearest device pixel (minimum 1), so we'll be rounding borders unnecessarily to a multiple of 2 screen pixels. That's one case where we actually tune our layout based on the size of a device pixel, so we actually want to do a reflow when the size of a device pixel changes (which is rare anyway I hope!). We need to tell layout the truth about the size of a device pixel. If we try to do that by keeping device pixels unchanged and fixing the above problems by passing around extra information about the true size of a device pixel, it'll be tons of work that adds a lot of unnecessary complexity to layout. I think it'd be a lot less work and a lot more maintainable to change the Mac nsIWidget implementation to work with device pixels that match actual screen pixels. If we do that, we'd still need similar changes to the native theme implementation so that the widgets are upscaled correctly.

Here's my overkill experiment to introduce screen points. Screen points need to be in fractional units, so I've used gfxFloat (as "double" in idl) and gfxRects, but that's probably a bad idea since this type already has an existing meaning ("fractional dev pixel for rendering" or something like that), and it's prefixed and obsoleted by prefix-free types, etc. The reason I did this was that a new type causes the compiler to point me to all the conversion points that need to be updated. And the rabbit hole goes pretty deep... This patch is really incomplete and up to now only compiles for 64bit mac builds. Here's a summary of the juicy portions: - nsDeviceContext asks nsIWidget for its DevPixelsPerScreenPoint and bases all conversions on that. - all screen pixels APIs now use screen points (except some DOM APIs that use int css pixels, and nsIWidget invalidation and plugin clipping is still dev pixels) - system font size conversion in nsRuleNode.cpp expected nsILookAndFeel font sizes to be in dev pixels; changed that to screen points ^ this is also the reason that text is too small when changing the devPixelsPerPx pref - added ClientSurfaceSize to nsIWidget so that OpenGL viewport size is correct - did the context scale inversion in drawRect (see beginning of comment 61) There's probably more but I can't think of anything atm. I haven't tested plugins with this patch, and selection drag image rendering is broken, and there are a few XXX comments that need to be addressed, but apart from that it works pretty well.

Handling dynamic resolution changes is surprisingly easy. Anyway, that's all I have and my time for this is up, so good luck Steven :)

That patch is an incredible effort but do you really think it's simpler than adjusting the Mac implementations of APIs that work with device pixels?

I haven't had any chance to work on this in the last week or so. I've been clearing the decks of more urgent bugs (notably those having to do with support for the Lion fullscreen mode, which will appear for the first time in a release in FF 14). But now I'm done. The first thing I'll do is read carefully through Apple's docs, then through Markus' patches. That should give me some idea how to proceed.

For those who are curious, I've found a way to improve Firefox's appearance in HiDPI mode while making no changes at all in cross-platform code. (The patch needs a bit more work, so I'll post it on Monday, together with a tryserver build.) Some things look just as good as in Safari -- for example the zebra graphic and the text in the Retina MBP ad at http://www.apple.com/. Other text (for example in the location bar) looks better than in current nightlies, but not quite as good as in Safari. All my tests have been with OpenGL on (with layers.acceleration.disabled off, as it is by default). By the way, I did confirm that Firefox nightlies look just as good as Safari when you turn OpenGL off. At least all text looks just as good.

(Following up comment #68) Where, in my new build, the text looks better than in FF nightlies but less good than in Safari, it appears that it's the same resolution as in FF nightlies (half that of Safari) but has been antialiased (as it isn't in Firefox nightlies). Why this is I don't know. I'll attempt to find out more on Monday.

Here's the patch I promised on Friday. On retesting, I decided that nothing in it looks as good as in Safari -- even the zebras graphic and the text in the Retina MBP ad at http://www.apple.com/. But everything looks better in it than in a current mozilla-central nightly. (With OpenGL on, that is.) I now think that *everything* (including the zebras graphic) is somehow "antialiased". I've started a tryserver build, which should be available in a few hours. I'm particularly anxious to hear from testers who have the new Retina MBP -- I still don't have mine. Clearly we've got more work to do. But at least this patch is a start. (Followed up in next comment).

(Following up comment #70) Apple's HiDPI mode is a strange beast: Apple *doesn't* want apps to just start behaving as if the screen contained four times as many pixels as previously (their number doubled horizontally and vertically) -- this would just make every UI object four times as small (twice horizontally and twice vertically). They *do* want each UI object to (potentially) have four times the detail as previously. Given this, I don't think we should change the resolution at which we lay out Firefox, or even necessarily at which we draw Firefox. If we find (as we do when not using OpenGL) that Apple automatically handles the (potentially) increased resolution correctly, I think we should let them do it. We should only intervene when (as in the case of OpenGL) Apple's automatic handling (its pixel doubling) *doesn't* work correctly. My patch from comment #70 somehow adds "antialiasing" to Apple's pixel doubling. This does improve our appearance, but is only a stopgap. Over the next few days I'll be looking through OpenGL code for places where I can make it optionally use more pixels than "normal". Benoit, you're probably the one who knows our OpenGL code best. Do you have any suggestions how I should go about this?

Here's a tryserver build made with my patch from comment #70: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-17fb66eca567/try-macosx64/firefox-16.0a1.en-US.mac.dmg If you're able to test in a HiDPI mode please try it out -- particularly if you have a Retina MacBook Pro. I'm particularly interested in how it compares to Safari and to current mozilla-central nightlies. Since the Retina MBP ad at http://www.apple.com/ (particularly the zebras graphic) was surely intended to show off the new Retina displays, that's a good place to start.

Wikipedia homepage in Safari (left) & Firefox try build (right) on Retina MacBook Pro With graphics acceleration enabled. It's definitely filtering/antialiasing the final output (which it didn't used to), but it looks like it's still scaled up from low resolution.

Also a warning -- http://www.apple.com/ doesn't load the high-resolution zebra image in Firefox; I think it's explicitly checking for Safari. You can grab the image direct however, and with it zoomed out you can easily see the difference between full resolution and pixel-doubling. http://images.apple.com/home/images/macbookpro_hero_2x.jpg This screenie is with acceleration disabled -- so you can see it looks great in the side-by-side at full res.

And here with acceleration enabled on the try build -- image renders blurry, definitely getting squashed to low resolution somewhere in the pipeline.

Looking at the JavaScript on http://www.apple.com/ it's checking for window.devicePixelRatio to determine whether to load high-res images. Bug 564815 requests implementation of that interface.

Using the test build in comment 72, top down: no accel, accel, safari.

(In reply to Steven Michaud from comment #71) > Apple's HiDPI mode is a strange beast: Apple *doesn't* want apps to > just start behaving as if the screen contained four times as many > pixels as previously (their number doubled horizontally and > vertically) -- this would just make every UI object four times as > small (twice horizontally and twice vertically). They *do* want each > UI object to (potentially) have four times the detail as previously. Of course. > Given this, I don't think we should change the resolution at which we > lay out Firefox, or even necessarily at which we draw Firefox. Yes we should. Layout knows about the difference between "CSS pixels" (resolution independent) and "device pixels" (resolution dependent). We take advantage of knowledge of device pixels to do resolution-dependent work such as sizing internal buffers and other things I described in comment #63 --- e.g. rounding border widths to device pixels and snapping text baselines and underlines to device pixels. We need to exploit that support instead of working around it, and that means we have to change the ratio of device pixels to CSS pixels so that device pixels match screen pixels. I will r- any approach that doesn't do that.

> I will r- any approach that doesn't do that. Even if your approach doesn't work with Apple's HiDPI mode? I'll keep an open mind about what you say. It may very well turn out to be the right way to do things. But I ask that you also keep an open mind.

(In reply to Steven Michaud from comment #79) > > I will r- any approach that doesn't do that. > > Even if your approach doesn't work with Apple's HiDPI mode? Unless HiDPI mode is very strange and won't let us get our choice of pixels on the screen, there will be a way to make it work. So I suggest you at least try my approach first.

(In reply to Brion Vibber from comment #74) The 2x (retina) Zebra asset is called by safari via a window.devicePixelRatio check. If a value of 2 is returned, http://images.apple.com/home/images/macbookpro_hero_2x.jpg is used. Otherwise, http://images.apple.com/home/images/macbookpro_hero.jpg is used. This is common logic on most of apple's site. (For this page the logic is in http://images.apple.com/global/ac_retina/ac_retina.js ) Apple recommends you check display resolution via window.devicePixelRatio in js or -webkit-min-device-pixel-ratio. They have also proposed the image-set function in css level 4.

(In reply to Mike Deerkoski from comment #81) Note related bug: -moz-device-pixel-ratio misreported as 1.0 instead of 2.0 on Mac HiDPI display http://bugzilla.mozilla.org/show_bug.cgi?id=765914 -device-pixel-ratio is being returned as 1, on an apple HiDPI display, while safari returns 2.

(In reply to Mike Deerkoski from comment #82) > Note related bug: -moz-device-pixel-ratio misreported as 1.0 instead of 2.0 > on Mac HiDPI display > http://bugzilla.mozilla.org/show_bug.cgi?id=765914 Right, that will be fixed if we take approach in comment #78.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #66) > That patch is an incredible effort but do you really think it's simpler than > adjusting the Mac implementations of APIs that work with device pixels? It's definitely not the simpler patch, but it might save us some headaches in the long run. I've thought about this a little more, and while I haven't found a really convincing argument, here are the ones that I've come up with: - When somebody adds a new widget API and forgets about OS X HiDPI mode, we're more likely to fail gracefully. For example, say we add a canvas-as-dragimage feature (which we already have, but assume we didn't), I could imagine that with the device pixel approach we'd map one canvas pixel to one device pixel by default, which would make the image too small under HiDPI. - Having the screen point unit makes people less like to forget about HiDPI mode when adding widget APIs. (But it would also make them aware of it even when their work doesn't have any implications on HiDPI, which would be an unnecessary cognitive load, which is bad.) - The total number of unit conversion calls might be lower with the screen point approach. Sure, the initial patch needs to change many conversion calls, but it doesn't add many additional conversions, it only changes which units to convert from/to. (Again, I'm cheating a little here since I haven't looked at the implications for widget API implementations on other platforms; if those have to introduce casts to integer everywhere, this argument is nullified.) - Debugging widget API calls under OS X HiDPI mode is more confusing when everything is in dev pixels because one needs to halve all numbers when comparing them to the ones we get from Cocoa. - I see some merit to the advice that the HiDPI documentation gives, that we should only be aware of dev pixels when we must, and treat window / screen dimensions independently from them. But the practical implications of this are probably mostly in backward- / forward-compatibility, which we have already anyway because we use appunits / css pixels internally. In any case, the decision for the right approach is up to you, roc :)

(In reply to Markus Stange from comment #84) > - When somebody adds a new widget API and forgets about OS X HiDPI mode, > we're more likely to fail gracefully. For example, say we add a > canvas-as-dragimage feature (which we already have, but assume we didn't), I > could imagine that with the device pixel approach we'd map one canvas pixel > to one device pixel by default, which would make the image too small under > HiDPI. This isn't a new issue since we already have conversions between CSS pixels (which canvas sizes are specified in) and device pixels, which are not 1:1 when a Web page is zoomed for example. > - Having the screen point unit makes people less like to forget about HiDPI > mode when adding widget APIs. (But it would also make them aware of it even > when their work doesn't have any implications on HiDPI, which would be an > unnecessary cognitive load, which is bad.) True I guess, although nsIntRect/nsIntPoint is already consistently used for device pixels throughout layout. The only thing we'd be changing here is that Cocoa pixels != device pixels. > - The total number of unit conversion calls might be lower with the screen > point approach. Sure, the initial patch needs to change many conversion > calls, but it doesn't add many additional conversions, it only changes which > units to convert from/to. (Again, I'm cheating a little here since I haven't > looked at the implications for widget API implementations on other > platforms; if those have to introduce casts to integer everywhere, this > argument is nullified.) Maybe but we don't call in and out of widget all that often so I don't think this matters much. > - Debugging widget API calls under OS X HiDPI mode is more confusing when > everything is in dev pixels because one needs to halve all numbers when > comparing them to the ones we get from Cocoa. True. > - I see some merit to the advice that the HiDPI documentation gives, that > we should only be aware of dev pixels when we must, and treat window / > screen dimensions independently from them. But the practical implications of > this are probably mostly in backward- / forward-compatibility, which we have > already anyway because we use appunits / css pixels internally. That might be more true for regular apps that don't already have an implementation specialized to work with knowledge of device pixels. Even if we took all those points as given, it wouldn't change the fact that we have a ton of code in layout that depends on knowing what a device pixel is, and we need to tell it the truth.

An alternative that would work is to redefine all the coordinates in widget interfaces to be CSS pixels, make them the same as Cocoa pixels on Mac, and introduce conversions from CSS pixels to device pixels (or vice versa) everywhere we use widget coordinates in Gecko. We would still use GetDefaultScale() to compute the default device pixel to CSS pixel ratio (although it might make sense to rename it). We currently don't have any platforms using GetDefaultScale() so we could do this only changing cross-platform code; widget implementations would not have to be changed. Whether this is a good idea partly depends on whether the platforms where we introduce high-DPI modes in the future use device pixels or some resolution-independent analogue of CSS pixels in their native widget APIs. E.g. Mac uses resolution-independent APIs in Cocoa, but if Windows and mobile use device pixels, then we'd have to sprinkle a lot of conversions in their widget implementations, and we'd sometimes be double-converting from the device pixels to CSS pixels and then back to device pixels in Gecko.

Ooh, I have another, very practical, argument: - When a window overlaps between a HiDPI and a non-HiDPI screen, window coordinates in device pixels are ambiguous. For example, if the left half of the window is on a HiDPI screen and the right half on a non-HiDPI screen, the window height on the left screen will be twice the number of device pixels compared to on the right screen. (Cocoa will change the window's backingScaleFactor dynamically depending on which screen the window occupies more area on, and the window manager will apply a scale when rendering the window on the other screen.) Gecko somewhere has a FindScreenForWindow method IIRC, and this method will have a hard time finding the right screen if it doesn't know which screen the device pixel coordinates are relative to. > Even if we took all those points as given, it wouldn't change the fact that > we have a ton of code in layout that depends on knowing what a device pixel > is, and we need to tell it the truth. In the screen point patch pretty much all of this works correctly, I think. There are methods that convert between screen points and device pixels and I think I got most of the callers right. (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #86) I'll think about this a little.

(In reply to Markus Stange from comment #87) > - When a window overlaps between a HiDPI and a non-HiDPI screen, window > coordinates in device pixels are ambiguous. For example, if the left half of > the window is on a HiDPI screen and the right half on a non-HiDPI screen, > the window height on the left screen will be twice the number of device > pixels compared to on the right screen. (Cocoa will change the window's > backingScaleFactor dynamically depending on which screen the window occupies > more area on, and the window manager will apply a scale when rendering the > window on the other screen.) Gecko somewhere has a FindScreenForWindow > method IIRC, and this method will have a hard time finding the right screen > if it doesn't know which screen the device pixel coordinates are relative to. I don't see the problem there as long as we always stay in sync with Cocoa about what screen the window is on and what its backingScaleFactor is. I'm pretty sure we'll need to do that whatever solution we pick. > In the screen point patch pretty much all of this works correctly, I think. > There are methods that convert between screen points and device pixels and I > think I got most of the callers right. Do we definitely need to support fractional screen points? If so, then maybe if we replace "screen points" with "CSS pixels" then your patch is the right thing. However I would like to know about high-DPI mode on other platforms. As far as I can tell, on Windows, when we declare ourselves to be "DPI aware" then all Windows APIs will still be working in device pixels. So if we take your patch then all the problems you're trying to avoid on Mac will crop up on Windows, but in reverse.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #88) > I don't see the problem there as long as we always stay in sync with Cocoa > about what screen the window is on and what its backingScaleFactor is. I'm > pretty sure we'll need to do that whatever solution we pick. Hmm, possible. I'd need to look at the code. > > In the screen point patch pretty much all of this works correctly, I think. > > There are methods that convert between screen points and device pixels and I > > think I got most of the callers right. > > Do we definitely need to support fractional screen points? Not yet, as far as I can tell. Mouse coordinates and window dimensions were always integer screen points in my tests. I chose gfxFloat / gfxRect because using a different C++ type makes it clear that other coordinate types need an explicit conversion, and because Cocoa uses CGFloat which is a double, too. > If so, then maybe > if we replace "screen points" with "CSS pixels" then your patch is the right > thing. > > However I would like to know about high-DPI mode on other platforms. As far > as I can tell, on Windows, when we declare ourselves to be "DPI aware" then > all Windows APIs will still be working in device pixels. OK. > So if we take your > patch then all the problems you're trying to avoid on Mac will crop up on > Windows, but in reverse. It would happen if we widget APIs were in CSS pixels, like you've suggested. But it doesn't happen with my patch because I'm not using GetDefaultScale. Instead, I've added nsIWidget::DevPixelsPerScreenPoint and left GetDefaultScale at 1.0 just so that other platforms can keep a 1:1 screen point per dev pixel ratio and still use the GetDefaultScale magnification capability. In my patch, GetDefaultScale gives the number of screen points per CSS pixel, not the number of device pixels per CSS pixel. You can see this in the change to nsDeviceContext::SetDPI: both screenPointsPerCSSPixel and mDevPixelsPerScreenPoint come from the widget (or the pref), and they're multiplied to get devPixelsPerCSSPixel which then gives mAppUnitsPerDevNotScaledPixel.

Roc, I see your point about being reluctant to lie to layout and gfx about device pixels. And surely we want to eventually not have to lie, on any platform that supports HiDPI. But it sounds like this will be a lot of work, and will take us a while (especially to iron out the kinks that this work is likely to introduce). It'd help if we had quicker ways to partially implement support for Apple's HiDPI mode -- ones that could be backed out once we'd figured out how to implement full support correctly. That's what I'm going to be working on ... at least for a few days, and unless I find that it doesn't pan out. Right now, as best I can tell things work just fine on the Mac in HiDPI mode when we don't use OpenGL, even though we're (in effect) lying to layout and gfx about device pixels. (There may be problems, but they don't appear to be gross ones. Do please suggest, though, where we might look to find them.) It's hard to say *why* we don't see gross problems. But it may help that all of our bitmapped "assets" (window chrome, icons and so forth) are still at their old, low resolutions. It's hard to tell, but I think our bitmapped assets look the same in HiDPI mode as they do in non-HiDPI mode, even when we don't turn on OpenGL. But it's striking how much better our fonts look in HiDPI mode (if we don't turn on OpenGL). I'm hoping that if we don't (for the time being) increase the resolution of our bitmapped assets, layout and gfx won't be too badly effected by being lied to about device pixels. I'm also hoping that I can hack out a way to make our fonts look as good (in HiDPI mode) with OpenGL on as they do with OpenGL off, without having to lie too atrociously to layout and gfx.

(In reply to Steven Michaud from comment #90) > Roc, I see your point about being reluctant to lie to layout and gfx about > device pixels. And surely we want to eventually not have to lie, on any > platform that supports HiDPI. But it sounds like this will be a lot of > work, and will take us a while (especially to iron out the kinks that this > work is likely to introduce). I think we should try to do things right now instead of piling up more technical debt. > Right now, as best I can tell things work just fine on the Mac in HiDPI mode > when we don't use OpenGL, even though we're (in effect) lying to layout and > gfx about device pixels. (There may be problems, but they don't appear to > be gross ones. Do please suggest, though, where we might look to find them.) box-shadow, text-shadow, animated CSS opacity on an element containing text, CSS filters and SVG masks on elements containing text. I don't expect those things to look worse. They just won't look better where they would look better if we do things right.

(In reply to Markus Stange from comment #89) > Not yet, as far as I can tell. Mouse coordinates and window dimensions were > always integer screen points in my tests. > I chose gfxFloat / gfxRect because using a different C++ type makes it clear > that other coordinate types need an explicit conversion, and because Cocoa > uses CGFloat which is a double, too. We can easily create new rect and point types that use integer coordinates but are different from nsIntRect and nsRect. I think we should do that since otherwise we're introducing a whole lot of floating point conversions that non-Mac platforms don't need. > > So if we take your > > patch then all the problems you're trying to avoid on Mac will crop up on > > Windows, but in reverse. > > It would happen if we widget APIs were in CSS pixels, like you've suggested. > But it doesn't happen with my patch because I'm not using GetDefaultScale. > Instead, I've added nsIWidget::DevPixelsPerScreenPoint and left > GetDefaultScale at 1.0 just so that other platforms can keep a 1:1 screen > point per dev pixel ratio and still use the GetDefaultScale magnification > capability. In my patch, GetDefaultScale gives the number of screen points > per CSS pixel, not the number of device pixels per CSS pixel. > > You can see this in the change to nsDeviceContext::SetDPI: both > screenPointsPerCSSPixel and mDevPixelsPerScreenPoint come from the widget > (or the pref), and they're multiplied to get devPixelsPerCSSPixel which then > gives mAppUnitsPerDevNotScaledPixel. Ah, OK. So on Mac screen points == CSS pixels, but on Windows screen points == device pixels. That would work. However, I'm still not happy about the maintenance burden of adding yet another coordinate system, with Gecko converting from screen points to and from CSS pixels and device pixels :-( ... where on any given platform, some set of those conversions are always doing nothing. I still lean towards avoiding that by making all widget APIs use device pixels and adjusting Cocoa coordinates to device pixels in the Mac widget code.

Nightly 16.0a1 (2012-07-01) has regressed -- I'm no longer getting sharp high-resolution text either with acceleration off or on. I can confirm that going back to http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-06-30-03-05-32-mozilla-central/firefox-16.0a1.en-US.mac.dmg shows high-resolution text with acceleration off.

Interesting. I'll try to figure out what happened.

(In reply to comment #93) I've confirmed what you report. Text doesn't look as bad (in a HiDPI mode) as it does when using OpenGL, but doesn't look as high resolution as it used to. Here's the regression range in terms of patches landed: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f08d285b63b0&tochange=d9d61d199b11 I suspect the culprit is one of the patches for bug 539356. But I'll need to use hg bisect to confirm that (and find out which one).

The "culprit" is http://hg.mozilla.org/mozilla-central/rev/bd0a91621ea9 Matt Woodrow <mwoodrow@mozilla.com> Bug 539356 - Part 8b - Move painting of retained layers to the view manager flush, and only composite on the paint event. r=roc Which I can't (yet) make any sense of. I'll need to dig deeper to find out.

The patches in that bug make all our repainting go through temporary buffers in ThebesLayers. Those buffers are sized based on device pixels which is why they don't get any HiDPI treatment. That change is not only needed for bug 539356 but also to enable off-main-thread-compositing when we're not using GL --- basically we're making non-GL behave more like GL. So I wouldn't bother digging into that issue any further. That code is working as designed. Everything will be fine once we set up device pixels correctly for HiDPI.

(In reply to comment #97) I've found that the following patch (to current code) restores previous behavior (in a HiDPI mode when not using OpenGL): --- a/layout/base/nsPresShell.cpp Mon Jul 02 14:05:17 2012 +0200 +++ b/layout/base/nsPresShell.cpp Tue Jul 03 09:46:25 2012 -0500 @@ -5275,9 +5275,9 @@ return; } layerManager->BeginTransaction(); - if (layerManager->EndEmptyTransaction()) { - return; - } + //if (layerManager->EndEmptyTransaction()) { + // return; + //} NS_WARNING("Must complete empty transaction when compositing!"); } else { layerManager->BeginTransaction(); diff -r 155f67c2c578 view/src/nsViewManager.cpp --- a/view/src/nsViewManager.cpp Mon Jul 02 14:05:17 2012 +0200 +++ b/view/src/nsViewManager.cpp Tue Jul 03 09:46:25 2012 -0500 @@ -395,7 +395,8 @@ printf("---- PAINT START ----PresShell(%p), nsView(%p), nsIWidget(%p)\n", mPresShell, aView, widget); #endif nsAutoScriptBlocker scriptBlocker; - mPresShell->Paint(aView, nsRegion(), nsIPresShell::PaintType_NoComposite, false); + //mPresShell->Paint(aView, nsRegion(), nsIPresShell::PaintType_NoComposite, false); + mPresShell->Paint(aView, nsRegion(), nsIPresShell::PaintType_Composite, false); #ifdef DEBUG_INVALIDATIONS printf("---- PAINT END ----\n"); #endif No, I'm not suggesting we do this. I think it means that, as of the patches for bug 539356, we're no longer ever drawing directly to the screen, and that the only time we were doing so previously was on an "empty transaction". For this and other reasons (more about them in the next comment), I'm giving up my attempt to find a quick fix for this bug (aside from the patch I've already posted). As things now stand, no amelioration of this bug (aside from my patch from comment #70) is possible short of a full and proper fix. So it'll take much longer to do anything about this bug (aside from my patch) than I'd originally hoped.

Every call we make to draw text goes through CGContextShowGlyphsWithAdvances(), called from _cairo_quartz_surface_show_glyphs_cg(): http://hg.mozilla.org/mozilla-central/annotate/f38d6df93cad/gfx/cairo/cairo/src/cairo-quartz-surface.c#l2678 http://hg.mozilla.org/mozilla-central/annotate/f38d6df93cad/gfx/cairo/cairo/src/cairo-quartz-surface.c#l2825 After discovering this, I spent several days last week digging around in cairo code looking for a way to up the resolution at which we draw glyphs. I didn't find any. My most promising idea was to double the size of all the bitmaps we create in cairo-quartz-surface.c and of their (undocumented) "resolution" (accessible using the undocumented CGFloat CGContextGetResolution(CGContextRef)). This made no difference that I could see.

Here's my patch from comment #70, updated to current trunk code. This patch doesn't do much. But it *does* improve the appearance of Firefox in HiDPI mode when OpenGL is on (as it is by default). And it's our only viable candidate for a quick "fix". Here's a tryserver build made from it: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-3dca4d51c4eb/try-macosx64/firefox-16.0a1.en-US.mac.dmg This is nothing new -- it hasn't changed from my previous patch. So don't comment on it unless you have something to say that wasn't already said about my patch from comment #70 (and its tryserver build from comment #72).

Now that (aside from my "antialiasing" patch) I've given up trying to find a quick fix for this bug, I'm going to spend some time trying to get Cocoa widgets to use device pixels. I won't be able to work on this full time (I've got to keep up with topcrashers and the like). But I hope to be able to spend a few days on it next week.

This is a screenshot of some text in Firefox 13. The zoom level in Firefox is default. The text does not improve when zoomed up or down. The only way to make the text look pretty that I've found is to use a third party utility to set the rMBP resolution to the native 2880x1800 which makes everything tiny but then Firefox fonts are pretty and if I zoom them up with Firefox zoom controls they become legible in size and stay pretty.

I guess that's MacOS just pixel-doubling our window and that looking bad due to subpixel text basically not working in that scenario.

Asa, do test with my tryserver build. The text in it looks quite a bit better than in FF 13, though not so good as in Safari.

Steven - tried your build on my retina macbook and it just looks blurred compared to FF13 instead of pixelated, but still nowhere near as good as Safari or Chrome Dev.

Just a brief status update... I've taken Markus's patches here and am working on updating them for current trunk; the result seems to be working pretty well (in very limited pseudo-HiDPI testing), modulo plugins (untested) and drag images (definitely broken). I'm hoping to have a tryserver build up later today so that people can try it on a real rMBP. In parallel, I'm also trying to pull together a less-invasive approach based on Roc's suggestions here; that's significantly further from being usable at this point (I have some lovely hi-res rendering, but only filling a quarter of the window; and lots of the UI is not properly scaled). No ETA on this yet - there are far too many coordinates and rectangles still in flight....

Tryserver build based on mstange's screenPoints patches is available at https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jkew@mozilla.com-fc19680644a8/. This certainly won't pass all tests, etc., but it should at least be usable (I hope).

I have installed Jonathan's try build (OSX 64). The trybuild is looking much better than FF13 or FF15 (Aurora). I am having trouble distinguishing it from Safari on sites like Wikipedia. Apple's site still shows pixelation due to using images for text. I have taken screenshots of the browsers on Apple.com/Wikipedia. Apple.com: https://dl.dropbox.com/u/1736241/Screenshots/n1.png Safari https://dl.dropbox.com/u/1736241/Screenshots/n2.png FF15 Aurora https://dl.dropbox.com/u/1736241/Screenshots/n3.png FF16 TryBuild (Jonathan) Wikipedia.org: https://dl.dropbox.com/u/1736241/Screenshots/n4.png Safari https://dl.dropbox.com/u/1736241/Screenshots/n5.png FF15 Aurora https://dl.dropbox.com/u/1736241/Screenshots/n6.png FF16 TryBuild (Jonathan) The Apple page is using HiDPI images that we aren't requesting yet due to device pixel ratio not equaling 2 on the HiDPI screen. Wikipedia uses regular text everywhere and is looking fantastic on the TryBuild.

Just got my Retina machine, and indeed :jfkthame's Try build looks very good. <select> menus are fairly messed up, not sure if that's expected.

I wasn't aware of <select> being messed up, so thanks for mentioning it. Looks like the menu itself displays fine, it's just displayed in the wrong place, yes? That should be a relatively simple fix, I hope.

It's displayed in the wrong place, and making selections with the mouse is... odd. Visually, the highlight follows the mouse, but the selection that gets made is different, possibly what would be under the mouse pointer if the menu were drawn in the correct location? Making selections with the keyboard works fine.

Jonathan, you build looks much much better on my retina MBP. Worth noting - the address bar doesn't seem to reflect the current URL (just the last one input) and the back/forward buttons don't work...

I does look much better on my rMBP too. I don't have address bar issues but select elements displays wrong as Jonathan said. Here's an example: https://dl.dropbox.com/u/5262061/ff-nightly-select-retina.png

I can reliably crash this build by dragging the horizontal scroll bars in the screenshots frame at http://itunes.apple.com/app/dashcommand-obd-ii-gauge-dashboards/id321293183?mt=8

There's another tryserver build at https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jkew@mozilla.com-7b69fc1a2452/. This one should handle <select> menus better, and no longer has scrambled drag images for text selections. Plugins (e.g. Flash) aren't fully working yet.

(In reply to Jonathan Kew (:jfkthame) from comment #116) > There's another tryserver build at > https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jkew@mozilla.com- > 7b69fc1a2452/. This one should handle <select> menus better, and no longer > has scrambled drag images for text selections. Plugins (e.g. Flash) aren't > fully working yet. Looks good so far on my Retina MBP; I'll try using this for a couple days and see if anything explodes. :) I had one machine crash when first launching, but haven't reproduced it again yet. Confirmed the <select> problem is resolved. Switching between HiDPI and non-HiDPI seems to work fine (using SwitchResX); I'm at a conference so can't test external monitors / mixed densities just yet.

Text looks much better on my rMBP. The UI text is also HiDPI, although the UI elements aren't, e.g. tabs and buttons. Scrolling is slower than Safari, but I don't know if that is the fault of this bug. -webkit-min-device-pixel-ratio is unsupported obviously, since it is a webkit prefix. Is there a -moz-min-device-pixel-ratio yet? If so, I will update my website.

(In reply to will from comment #118) > -webkit-min-device-pixel-ratio is unsupported obviously, since it is a > webkit prefix. Is there a -moz-min-device-pixel-ratio yet? If so, I will > update my website. It's moz--min-device-pixel-ratio... I have an example on bug 765914 which seems to show it working as expected with this build. Yay!

Or min--moz-device-pixel-ratio rather.

Thanks! High Def images work on the build with the min--moz-device-pixel-ratio css media query. I have updated my blog accordingly... Why is it min--moz-device-pixel-ratio rather than -moz-min-device-pixel-ratio? That seems weird. http://www.manystrands.com/

Selects work, and I can't crash the browser as described in comment 115, but two-finger scrolling doesn't work in that frame. (may be unrelated) Something I've noticed in both builds: The first time after launch, if you download a file, the door-hanger showing download status will slowly shrink until it needs scroll bars. I tested with the regular nightly and did not see this behavior. (Though, the text in the door-hanger is rendered at HiDPI in the regular nightly, even though nothing else is)

(In reply to Zandr Milewski [:zandr] from comment #122) > Selects work, and I can't crash the browser as described in comment 115, but > two-finger scrolling doesn't work in that frame. (may be unrelated) I think that's unrelated - I'm finding that frame quite unresponsive to two-finger scroll in a standard Nightly build as well. I can kind of "nudge" it a little bit at a time, but I can't get a proper scrolling motion to work. > Something I've noticed in both builds: > The first time after launch, if you download a file, the door-hanger showing > download status will slowly shrink until it needs scroll bars. That's....weird!

Another minor glitch I'm seeing in HiDPI mode with these patches is that the status-bar overlay thing (not sure what it's officially called) that shows link targets, etc, in the bottom corner of the window does not skip away from the mouse to the opposite corner.

I've tried the build from comment 116, and it runs very smoothly. Text is displayed in high-resolution as expected, the Flash plugin worked perfectly for me. Minor (and probably already known) issues are: lack of high-res Firefox artwork (icons and the like). The two real issues I observed are: 1. high-res images in webpages like http://www.apple.com/ are not picked up 2. The Web Developer "Inspect" mode highlights rectangles at totally wrong positions (see attached screenshot for an example). Seems the unit conversion is not done properly there.

Also of note: using the HiDPI build, the favicon doesn't appear next to the URL as it usually does. It does appear in the tab, however.

Using comment's 116 [patched build of Firefox](https://bugzilla.mozilla.org/show_bug.cgi?id=674373#c116) which handles HiDPI rendering on the new MacBook Pro with Retina display, I tried the viewer example at http://mozilla.github.com/pdf.js/web/viewer.html The rendering of pdf.js on this HiDPI build is incorrect, with the text being rendered all blurry. The attached screenshot compares FF's rendering (top) to Safari's crystal-clear text on the same page (bottom).

Adding to comment 128, all canvas operations are performed in low resolution mode (and thus give blurry rendering). See the attached screenshot of this page: https://developer.mozilla.org/samples/canvas-tutorial/2_5_canvas_quadraticcurveto.html where patched FF is on the left, and Safari on the right.

After more testing, I continue with my list of things that appear in low resolution in the high-res patched nightly: WebGL also has this issue, which can be seen on the screenshot attached of the demo at https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/demos/google/particles/index.html On the screen capture, compare patched FF's low-res WebGL on the left, to Chrome beta's high-res WebGL on the right.

Thanks FX. Those last three issues should be filed as separate bugs since they require extra work to be made DPI-aware.

The tryserver build is better than the original patch in that it works with hardware acceleration on. However, there's a few quirks, namely with plugins. Some don't accept input at all, others very inconsistently. Youtube videos also have their chrome rendered in HiDPI mode, making the controls very hard to access. Cheers,

Using the latest tryserver build (found in the directory tree mentioned above).. While the text looks good on a Retina display, when you move the window onto a screen that's not Retina capable - the icons get messed up on the URL line (i.e back, forward, home, downloads, etc.) They appear with a box around them. I attached a screen capture to look at (sorry for the poor quality as I had to convert from a video since the window has to be in focus to see the issue and window capture wouldn't allow me to do that.) Finally, video controls (such as Youtube) don't get rendered properly (all in in HiDPI mode.)

Which is the latest tryserver build that works. Many of the links in past comments doesn't work any more

Using the last tryserver build... Dragging a tab from a window on a HiDPI screen (internal retina MBP) to a non-HiDPI screen (Dell U2410) creates as new window as expected, but draws all the text at 2x. UI widgets appear to be rendered in the right place, but associated text is a long way away. Curiously, *taking a screenshot* caused all the text to re-render in the right place, but still at 2x size. Said screenshot attached. cmd-R fixes it.

There's a newer tryserver build at https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jkew@mozilla.com-efaf94ebbaaf/, based on a simplified version of Markus's screenPoints patch where "screen points" are integer rather than floating-point coordinates. This also fixes a couple more things that weren't working properly, including the status panel mouse-avoidance behavior. Many plugins will still have problems, and I haven't looked into the tab-dragging issue that was just reported above.

Posting current WIP, in case anyone wants to play with it... this is the basis of the tryserver build above. Known to still have plugin problems and a few unit test failures.

(In reply to Jonathan Kew (:jfkthame) from comment #138) > There's a newer tryserver build Going back over the things I listed in my earlier comments as not working properly, the status of this new build is: 1. Inspect feature is now working okay 2. HiDPI images are still not picked up on pages like www.apple.com 3. Favicon still does not appear next to URL 4. WebGL still low res 5. canvas still low res

(In reply to FX from comment #140) > (In reply to Jonathan Kew (:jfkthame) from comment #138) > > There's a newer tryserver build > > Going back over the things I listed in my earlier comments as not working > properly, the status of this new build is: > > 1. Inspect feature is now working okay Great, thanks for testing. > 2. HiDPI images are still not picked up on pages like www.apple.com Judging by the testcase in bug 765914, this should work if the site uses the -moz-prefixed version of device-pixel-ratio; presumably the Apple site is only using the -webkit-prefixed version, and therefore serves us low-res images. > 3. Favicon still does not appear next to URL I'll try to look into this. > 4. WebGL still low res > 5. canvas still low res These issues should be handled as separate followup bugs, I think.

The favicon was dropped from the address bar in nightlies a few months ago and is now like that in Firefox 14: https://msujaws.wordpress.com/2012/04/23/an-update-to-site-identity-in-desktop-firefox/

Sure enough - thanks. OK, no favicon issue to worry about here, then.

Another issue: caret drawing is not correct in comment 138's linked tryserver build. - In a text box, the caret is initially drawn as expected, with a width of two pixels, but when it is erased (either to make it blink, or because its position changes using back), most of the times only half of the pixels are erased, leaving behind a one-pixel wide "ghost" of the caret. - Sometimes, after moving the caret forward and back in a text, it will draw at half the size (one pixel width instead of two pixels). I attach a screenshot of the caret (ghosts) one can see after erasing some text with backspace. PS: I've filed bug 780361 regarding the WebGL issue, and bug 780362 regarding the Canvas issue.

(In reply to FX from comment #144) > Created attachment 648972 [details] > Ghosts of caret > > Another issue: caret drawing is not correct in comment 138's linked > tryserver build. Interesting... do you have h/w acceleration disabled? I was unable to reproduce this with acceleration enabled, but after disabling it I see the issue here.

> Interesting... do you have h/w acceleration disabled? I was unable to > reproduce this with acceleration enabled, but after disabling it I see the > issue here. I have "Use hardware acceleration when available" checked. I don't suppose there's any reason it's not supported on my MacBook Pro Retina… It happens more often if you backspace entire words (keys: alt + backspace) than single letters.

Strange - I still can't reproduce with acceleration enabled (also on a Retina MBP). I wonder what's different. There's another issue I've observed that may be related, though: when I drag selected text, many of the glyphs in the drag image look as though they've had the rightmost column of pixels clipped off. Looks like it could be a rounding error (truncating instead of rounding the glyph widths when drawing, or something like that).

You probably need to do ScaleToOutsidePixels instead of ScaleToNearestPixels somewhere.

Been using the build from comment 138 for a couple days... For the most part it seems pretty reliable on the MacBook Pro Retina display... when there's a second or third monitor (low-resolution), I notice some slight glitches when switching a window between monitors: There seems to be a brief flash of improperly-scaled content, immediately replaced by new, correctly-scaled content. Every once in a while the window turns plain white, which is resolved by switching the window to the other screen again. Haven't seen any caret issues. (with acceleration enabled) On the Retina display there are some issues with plugins, but both Flash videos and Google+ Hangout appear to basically work. Flash videos seem to get high-resolution display without understanding it (tiny video controls), and right-click to open the flash menu opens a popup menu at the wrong screen position (some coordinate needs to be scaled?)

I have also been using the build from comment 138 since it was built on my MBP Retina with major issues. As Brion has mentioned, Flash is working but seems to be displaying hi-res/full screen images in the usual lo-res/small screen windows and I also have the issue with the right click context menu being a ways off to the bottom right. The issue with the flash resolution car really be seen in the Google Finance individual stock graphs. There is a similar issue when trying to move/drag a tab in the tab bar. The thumbnail image is offset a ways to the bottom right from its normal position. Strangely, the canvas graphs on AWFY are visibly lower resolution on this build then the regular nightly builds. The graphs look very sharp on a regular nightly build.

I've pushed another tryserver build that should fix the caret-drawing glitches described in comment 144, AFAICT - at least, I can no longer reproduce the problem, regardless of the hardware acceleration setting. This should be available in an hour or so at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jkew@mozilla.com-ddc58138cbc4. FX, please test this when it's ready and let me know whether it resolves the caret issues for you.

I just noticed that there are some "ghosts" left on many drop-down menus where there are many selections. This is seen using the build from this morning.

I'm having the same issue as on the first build with the Downloads Manager (it's slowly shrinking). The drop-down menus bug seems to be fixed though.

I spoke too soon, I'm still having drop-down menus ghosts sometimes, not every time.

Scrolling on this build seems to run at half speed also, compared to the normal firefox build. This makes browsing long pages a little bit tedious.

Updated patch, fixing a few more issues including scroll speed and highlight "ghosts" in drop-downs. Tryserver build should be available shortly at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jkew@mozilla.com-895e23d81758.

The nightly build does not render the www.apple.com website properly using retina graphics the way that Safari and Chrome both do. The menu-bar, page text, and the images are still pixelated.

(In reply to Antonio from comment #157) > The nightly build does not render the www.apple.com website properly using > retina graphics the way that Safari and Chrome both do. The menu-bar, page > text, and the images are still pixelated. That is a different bug; apple's JS is looking for -webkit-device-pixel-ratio to download the 2x images... which Firefox obviously doesn't support.

(In reply to Jonathan Kew (:jfkthame) from comment #156) > Created attachment 650498 [details] [diff] [review] > [updated WIP] patch to introduce HiDPI support using integer "screen points" > > Updated patch, fixing a few more issues including scroll speed and highlight > "ghosts" in drop-downs. Tryserver build should be available shortly at > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jkew@mozilla.com- > 895e23d81758. Looking good here, scrolling is back to normal. YouTube plugins are also easier to start playing, but still switch to HiDPI mode when clicked.

Jonathan, this is looking really good. I've been using it for a while and the only thing I've seen which looks odd is some tooltip/titletip boxes (on link hover) being kind of messed up, like the box has a notched in right border. I don't know how to capture it and though I don't see it in our release builds it could be unrelated to your changes. (mouse over date and name links in the attachments table on this bug page, for an example.) It seems inconsistent and I haven't figured why.

OK. I managed to get a screenshot.

I cannot reproduce in a regular latest nightly Mac build. Also, it's showing up for tooltips in Firefox chrome as well as content. Still can't figure out why it's not always reproducible on the same elements.

Also seeing SVG failing to render at, for example, http://svg-wow.org/gandhi-quotes/gandhi-quotes.xhtml which seems to work fine in latest official nightly.

(In reply to Asa Dotzler [:asa] from comment #161) > Created attachment 650798 [details] > broken titletip box > > OK. I managed to get a screenshot. That's weird! And now that you've mentioned it, I was able to reproduce almost immediately, although I hadn't noticed it at all until now. I also saw a case where the bottom edge of the titletip was uneven. (In reply to Asa Dotzler [:asa] from comment #163) > Also seeing SVG failing to render at, for example, > http://svg-wow.org/gandhi-quotes/gandhi-quotes.xhtml which seems to work > fine in latest official nightly. It looked somewhat flaky to me (I see some odd clipping, misplaced final periods, poorly-spaced final "Gandhi") in standard Nightly as well. But I think the main problem here may be that it's using an embedded SVG font, which we don't support, and therefore the text ends up completely differently-sized than was intended, and doesn't fit into the intended areas. (Compare how it looks in Chrome, for example.) So, while there may well still be SVG-related issues here, I don't think that particular example is a good basis for testing.

Agreed. Ignore the SVG issue for now. It wasn't concrete. The tooltip issue is also not terribly important if the symptom is limited to that case. I only raise it here (rather than a follow-up bug) in case there's something larger at play that might effect more significant parts of the user experience.

The YouTube player on youtube.com is actually working great (not switching into HiDPI mode)!

Comment on attachment 650936 [details] Bad redraw when dragged from non-HiDPI to HiDPI display I've noticed a couple of things when dragging between HiDPI and non-HiDPI: * Dragging between the two displays makes the window 'jerk' a little bit. I'm assuming it's because it's switching over, but it could be done more gracefully. * Dragging from non-HiDPI to HiDPI display leaves a ghost (see screenshot). Scrolling down scrubs the page clean and it's then displayed correctly.

Another plugin-related issue: Google+ Hangout (using Google's audio/video plugin) mostly works, but the individual people mini-screens don't show.

The vertical scroll bar target image is much smaller on "long" pages then the current nightly using the latest test build (image is from Planet Mozilla page). On the current nightly it is much larger.

(In reply to Jonathan Guerin from comment #168) > Comment on attachment 650936 [details] > Bad redraw when dragged from non-HiDPI to HiDPI display > > I've noticed a couple of things when dragging between HiDPI and non-HiDPI: > * Dragging between the two displays makes the window 'jerk' a little bit. > I'm assuming it's because it's switching over, but it could be done more > gracefully. Yes, the transition is a bit ugly. > * Dragging from non-HiDPI to HiDPI display leaves a ghost (see screenshot). > Scrolling down scrubs the page clean and it's then displayed correctly. I suspect this might be a more general problem related to redrawing content when the window is zoomed; I can reproduce something similar when zooming in standard Aurora and Nightly builds, without the HiDPI patches. Filed as bug 782262.

I've been using the last tryserver build on my MBP retina for about a week now. Flash doesn't work, but the text looks GREAT. I do have one notable issue that seems like a symptom of scaling not being exactly correct, nested bookmark toolbar folders. I'll try and upload an example, but when I mouse through the items one level deep of bookmark toolbar items it works ok (but not perfect) but when I get to two levels deep it's really bad and often just clicks off the menu so I can't even mouse to the lower items.

Updated tryserver build is at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jkew@mozilla.com-d7b36b67a324. I think this will fix the "ghost" described in comment 168; also fixes an issue with popup menus not scaling correctly when you zoom.

Using comment 174's build, I don't see caret ghosts anymore. I have however found another issue in the handling of the "Find" bar at the bottom of the window when cmd+F is pressed: most of the times, then "Find bar" does not display, but only the text field itself (white background, and then black text when other keys are pressed). The attached snapshot shows this. Then, when the text to find cannot be matched in the page anymore, the "Find bar" is redrawn, and now clearly visible. However, it's still not perfectly displayed: there are white areas of a few pixels to its left and right (see next attachment).

I've not been able to reproduce this Find-bar issue - it seems to appear reliably and draw correctly for me. Do you have any addons installed that might possibly be affecting it?

(In reply to Jonathan Kew (:jfkthame) from comment #177) > I've not been able to reproduce this Find-bar issue - it seems to appear > reliably and draw correctly for me. Do you have any addons installed that > might possibly be affecting it? It also happens without add-ons, if the add-on bar is displayed. It does not happen when the add-on bar is not displayed. It does not happen on the first search inside a page, but systematically happens on all subsequent searches.

(In reply to FX from comment #178) > (In reply to Jonathan Kew (:jfkthame) from comment #177) > > I've not been able to reproduce this Find-bar issue - it seems to appear > > reliably and draw correctly for me. Do you have any addons installed that > > might possibly be affecting it? > > It also happens without add-ons, if the add-on bar is displayed. It does not > happen when the add-on bar is not displayed. It does not happen on the first > search inside a page, but systematically happens on all subsequent searches. I can't seem to repro this on the new tryserver build either... I've tried enabling and disabling the add-on bar, but no luck.

I can reproduce this with a clean new profile, 100% of the time (I restarted Nightly six times to check), like this: 1. Display both Bookmarks toolbar and add-ons toolbar 2. Load https://www.google.com/ in a new window 3. Make the window less tall so that a vertical scrollbar appears 4. Search for "face" (which appears few times in the page): cmd+F, then "face" 5. Hit escape to dismiss the search bar 6. Search for "face" again ==> NOW THAT DOESN'T WORK PROPERLY

(In reply to FX from comment #180) > I can reproduce this with a clean new profile, 100% of the time (I restarted > Nightly six times to check), like this: > > 1. Display both Bookmarks toolbar and add-ons toolbar > 2. Load https://www.google.com/ in a new window > 3. Make the window less tall so that a vertical scrollbar appears > 4. Search for "face" (which appears few times in the page): cmd+F, then > "face" > 5. Hit escape to dismiss the search bar > 6. Search for "face" again ==> NOW THAT DOESN'T WORK PROPERLY I am unable to reproduce the bug with the latest try build, new window, toolbars open, short window: http://dl.dropbox.com/u/1736241/Screenshots/p1.png

Aha! I've now been able to reproduce the Find-bar problem as described, but *only* when I explicitly disable hardware acceleration (and restart the browser, so that change takes effect). With acceleration enabled, I can't get it to happen.

(In reply to Jonathan Kew (:jfkthame) from comment #182) > Aha! I've now been able to reproduce the Find-bar problem as described, but > *only* when I explicitly disable hardware acceleration Indeed, that's the second time this happens in this PR, so I double checked. So, I have the "Use hardware acceleration when available" setting checked, but in about:support Firefox Nightly says: Graphics Vendor ID: 0x10de Device ID: 0x fd5 WebGL Renderer: NVIDIA Corporation -- NVIDIA GeForce GT 650M OpenGL Engine -- 2.1 NVIDIA-8.0.51 GPU Accelerated Windows: 0 Azure Canvas Backend: quartz Azure Fallback Canvas Backend: none Azure Content Backend: none (in fact, Firefox 14.0.1 says the same thing) I find it very surprising because this is good hardware (brand new MacBook Pro Retina). I'll try and file a separate bug about this.

Interesting - I wonder why that's happening. Yes, please do file a separate bug for it. FWIW, I'm also using a retina-MBPro, but my about:support reports a different NVIDIA driver version (and OpenGL is used as expected): Graphics Vendor ID: 0x10de Device ID: 0x fd5 WebGL Renderer: NVIDIA Corporation -- NVIDIA GeForce GT 650M OpenGL Engine -- 2.1 NVIDIA-7.24.10 GPU Accelerated Windows: 1/1 OpenGL AzureCanvasBackend: quartz AzureFallbackCanvasBackend: none AzureContentBackend: none

This might be a dumb question, but are either of you perhaps running Mountain Lion?

I am unable to reproduce the issue. My hardware acceleration seems to be enabled and working fine and I have the same driver version as the person with no hwa. I am running Mountain Lion. Graphics Vendor ID: 0x10de Device ID: 0x fd5 WebGL Renderer: NVIDIA Corporation -- NVIDIA GeForce GT 650M OpenGL Engine -- 2.1 NVIDIA-8.0.51 GPU Accelerated Windows: 1/1 OpenGL AzureCanvasBackend: quartz AzureFallbackCanvasBackend: none AzureContentBackend: none I suspect this is an issue for a different bug report.

I suggest trying a new profile in case you have some non default preferences.

(In reply to Asa Dotzler [:asa] from comment #186) > I am unable to reproduce the issue. My hardware acceleration seems to be > enabled and working fine and I have the same driver version as the person > with no hwa. The difference appears to be that I open Firefox in 32-bit mode, in order for PDF to display natively in the browser (the Firefox PDF Plugin for Mac OS, which is 32-bit only). I have filed bug 782713 to track this.

Here's my Graphics (ML installed): Graphics Vendor ID0x10de Device ID0x fd5 WebGL Renderer NVIDIA Corporation -- NVIDIA GeForce GT 650M OpenGL Engine -- 2.1 NVIDIA-8.0.51 GPU Accelerated Windows1/1 OpenGL AzureCanvasBackend quartz AzureFallbackCanvasBackend none AzureContentBackend none

The new tryserver build appears to have serious trouble with Magic Mouse gestures (back and forwards)(trackpad ones seem OK). If I use the same gestures on Safari, they work fine. Not sure what's going on.

(In reply to Jonathan Guerin from comment #190) > The new tryserver build appears to have serious trouble with Magic Mouse > gestures (back and forwards)(trackpad ones seem OK). If I use the same > gestures on Safari, they work fine. Not sure what's going on. Just checked Firefox 14 and gestures work fine there too.

(In reply to comment #190) This is probably bug 782552 (and therefore unrelated to Jonathan's work here). You should see the same problem in today's mozilla-central nightly.

Thanks for the update!

Previous to 17.0a1 (2012-08-14), setting layers.acceleration.disabled to true would cause the text to look beautifully crisp and sharp on Retina displays. The 17.0a1 build broke this behaviour. Text is now blurry with acceleration enabled or disabled.

Confirmed - the last two Nightlies have broken HiDPI support. @Carsten, If you grab the .dmg from two nights ago it's still nice and crisp: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-08-13-03-05-32-mozilla-central/ Hope it's fixed soon though, as I'd rather have the benefit of all the other checkins... (although I realise Nightlies are potentially unstable, that's the point!)

(In reply to comment #194 and comment #195) I'll bet this is because one or more parts of the patch for bug 539356 (which were landed and backed out a few weeks ago) were relanded on 2012-08-13. See comment #95 and comment #96 above.

I'm posting an updated set of WIP patches. These are getting close to working, I think, with the notable exception of plugin issues. Part 1 is the basic support for "screen points" as the coordinate system for widget management, potentially distinct from device pixels, although by itself this doesn't enable actual HiDPI rendering.

The a11y changes from the screen-points patch, split out for my convenience. This really hasn't been tested yet.

This actually turns on HiDPI mode on OS X (when appropriate).

This is essentially Markus's patch for native theme rendering, with pretty minimal updates/rebasing.