Forums » Impact Engine » Impact looks really bad on MBPr in Safari

Hey Dominic,

On a MacBook Pro Retina display, Impact games look really bad in Safari. Very blurry. Here is Biolab Disaster in Safari 6 and Firefox 14, both on the same MBPr:

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

On standard displays Safari looks fine. Impact games in Chrome and Firefox both look just fine on retina displays.

This is Safari's bug, but figured I'd give you a heads up.

I wondered about how it would look on a retina display MBP. How does it compare to the retina display on an iPad?

I dunno, I don't have a retina iPad handy.

For a more extreme example, here is my game running in Retina Safari 6:

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

That don't look good :)

There also looks like there might be more bugs in Safari. In the middle towards the bottom, left of the boat, is a brown sign. It&039;s supposed to say something on it, but in Safari it just rendered the entire font image instead (!"$%....). This is standard impactjs font usage.

I have noticed intermittent font issues in Safari 6 on Mountain Lion, but I haven't figured out a way to reliably reproduce them yet.

As for the blurriness, you probably need to double your zoom and then use CSS width/height to resize the canvas down.

Oh, Apple and their retina head aches. What else is new.

All I can say is, this really really sucks.

I'm thinking HiDPI screens are pretty much the future... Apple is just, more or less, leading the charge. Like any major transition in tech... it'll be rocky for a bit.

I don't think it's the display here that is the issue, it's physics.

You have more pixels displaying more information and therefore you either have to draw those extra pixels or rely on the computer to resize the image to the larger size for you.

P.S. Dominic, can add a proper tab index to the save/post buttons to make it easier to Tab + Enter to post? :)

Ran a current project on our iPad 3 to test this. I definitely noticed a slight blurriness! Looks like maybe the scaling of the game in safari is using something other than point / nearest neighbour?

Even with the huge res of the iPad 3, my game shows up the same size as it does on iPad 2, so there has to be some scaling going on somewhere in safari (10 pixels wide should not look the same on both devices, but does).

I expected this fiddle to fail on HiDpi Safari:

http://jsfiddle.net/VAXrL/21/

But it doesn't, Safari renders it correctly. Also if I set my game's scale to 1, then it is rendered correctly (albeit quite tiny). I'm thinking impact might need to handle HiDpi Safari as a special case.

There is definitely something fishy going on here.

Check out my modified example in both Chrome and Safari on a Retina MBP:

Also, make sure you do not have an external monitor hooked up, so JUST the laptop screen.

http://jsfiddle.net/VAXrL/202/

The expected case is definitely what you see in Chrome but Safari has issues, allow me to explain.

For those unfamiliar, we are dealing with a retina display, so there are 2 values we will use, screen pixels, which refers to the actual physical pixels on the screen, and CSS pixels, which refers to what the browser CSS and DOM interpret as pixels. On a normal laptop/computer, this is a 1 to 1 relationship. 1 CSS pixel === 1 screen pixel. On a retina display, it's 2 screen pixels used for every CSS pixel, except in a few special contexts (canvas tags, images and background images).

We do this by making the canvas/image/background image TWICE as big in dimensions, then use the appropriate CSS styles of width/height or background-size to resize the image down. The browser is then smart enough to actually render ALL pixels at their native screen pixel size.

Referring to the example:

The default image is 64x64px, which means on a retina display if you left it as it is, the browser will automatically use 128x128 screen pixels to render. This will cause a certain level of image rescaling, which when left up to the browser, kinda sucks (generally).

To render it pixel perfectly, it's going to need to use CSS to resize the image or canvas down to 32x32 css pixels, which in turn would use the exact 64x64 screen pixels, and no image resizing is necessary.

In the above example, the red borders refer to images, and the blue borders refer to canvases.

The first row of image and canvas are just rendered as is, no CSS is used to resize them, so they are pixel doubled on a retina display, but will look perfectly normal on a non-retina display.

The bottom row however, have been resized using CSS, otherwise they are identical. If you look closely in chrome on a retina display, there should be no blurring (or image scaling) artifacts. This is the ideal way to work with retina imagery.

The issue though, is that in Safari it doesn't seem to work like that. The image is perfect, however the canvas is blurry, which leads me to believe there is some type of GPU bug in effect here.

If you want to get really weird. Hook up an external display to your computer, put the Safari window with the example on the external display, refresh the page, then drag it over to the retina display, and it performs the rescaling of the canvas tag perfectly (like in chrome).

I'll do some more digging tonight to see if there's perhaps a CSS way of undoing this weird bug.

Oh shit, I just figured this out.

This is now made a bunch more complex due to some new APIs in the canvas tag, specifically:

ctx.webkitBackingStorePixelRatio

This now means that all the logic that pertained to what I spoke about before on the canvas tag, now doesn't apply if this property exists. And because it's not supported in Chrome, you have to work around this in a different way for Safari vs Everyone else.

See the new example for details:

http://jsfiddle.net/VAXrL/206/

Essentially now, you need to check for the existence of context.webkitBackingStorePixelRatio, and if it does not exist then you're going to have to double the size of your canvas and use CSS to size it back down. If it does exist, you can use the normal CSS values for your width and height, but your drawImage methods (and probably other methods as well?) are going to need to be taken into account for this new difference. See here:

ctx.drawImage(img2, 0, 0, 64, 64, 0, 0, 32, 32);

or more specifically:

ctx.drawImage(img2, 0, 0, 64, 64, 0, 0, 64 / ctx.webkitBackingStorePixelRatio, 64 / ctx.webkitBackingStorePixelRatio);

Welp, through a bunch of experimentation and messing around, I have published a quick assessment of webkitBackingStorePixelRatio, what it does, and what it was intended for.

https://gist.github.com/3712795

Thanks for the awesome research Amadeus. Still wrapping my head around it all. But in the end, it does look like supporting all browsers including Safari on retina is doable from client code. Thankfully detecting retina displays is easy to do.

I'm personally not too worried about retina Safari to be totally honest. I don't expect my game to be ran in that environment much, if at all. I posted the issue because it seems like something impact in general might need to tackle.

Just wanted to chime in here: thanks for all the research city41 and Amadeus!

I wrote a blog post concerning all the different scaling methods for pixel art. At this point, it's a horrible mess.

Since I don't have a retina MBP, I'm really flying blind here. There are many open questions how Apple's new Canvas functions will behave in certain cases and - as far as I know - there's no way to test it, other than on the real hardware.

Amadeus has made some good progress in the last few days for what could become a plugin for Impact that works around this mess. At this point in time, I however won't implement these changes directly into Impact; not without the ability to test them.

I hope Apple will support imageSmoothingEnabled in the next Safari update. Setting this property to false would then be all it needs to make Impact work on the retina MBP again, if I'm not mistaken. I've reached out to some people at Apple and "lobbied" for their support; let's see how that goes.