TileMaps Broken in Safari (Phaser 2.2.0/1)

[neurofuzzy]

TileMaps are very broken in Safari, and it seems to be due to 1 line of code which, if I comment it out, makes everything work fine. I'd create a PR but I do not know exactly how this particular rendering flag is used:

The line is here:

https://github.com/photonstorm/phaser/blob/master/src/tilemap/TilemapLayer.js#L677

In method: Phaser.TilemapLayer.prototype.shiftCanvas

context.globalCompositeOperation = 'copy';

Example:

http://jsfiddle.net/zq8hn23g/6/

This works fine in all browsers except Safari. If you run the example, then click and drag on the canvas, you'll see the tilemap flicker in and out of visibility.

Please let me know if you need any more info.

[pnstickne]

@neurofuzzy sigh - if only it was easy for us non-Mac users to get access to Safari.

That line was specifically added for handling alpha tiles; if it is removed then I tiles that are partially transparent will result in "strange overdraw artifacts" (in at least IE/FF/Chrome, and maybe Safari). However, flickering is clearly not acceptable either..

..now,
Is this problem only when dragging the canvas? - or also during normal game/canvas redrawing?
What about if the canvas is moved via normal camera-follow (as in Sci-Fly demo)?
Also, does this affect the game in WEBGL as well, or only in CANVAS?

Earlier versions of the code used a secondary canvas buffer (and a clear), but didn't adjust the globalCompositionOperation itself.

[pnstickne]

@neurofuzzy Can you test the https://github.com/pnstickne/phaser/tree/wip-tilelayer-safaribug branch? I've altered the code to only specify the 'copy' operation once (when the TileLayer is created) and it eliminates the state save/load operations.

Here is the diff to reproduce the changes locally: pnstickne/phaser@photonstorm:dev...wip-tilelayer-safaribug

If this works I'll put in a PR.

[pnstickne]

Oops. That won't work correctly for tiles with transparencies (the background won't alpha) - however the results in Safari will help to isolate the issue further.

[neurofuzzy]

It's still bugged with that change. But, in this case it doesn't flicker - it is invisible except for the edge tiles (which are partially off-canvas).

The only thing I've gotten to work is simply commenting out context.globalCompositeOperation = 'copy'; and it works. In my particular case I do not have alpha.

UPDATE: Sorry forgot to answer: Yes, it happens when I drag or the camera moves across the world. If the camera stays so that the top left of the canvas matches 0,0 in the world, it will appear correctly.

By the way, if you have an iPad, iPod Touch or iPhone, you can test and get the same results. I'm of course happy to test anything you throw my way!

[neurofuzzy]

According to the w3schools site, 'copy' will display the source image, ignoring the destination image. It would seem that's not what we want. Try the playground:

http://www.w3schools.com/tags/playcanvas.asp?filename=playcanvas_globalcompop&preval=source-over

[pnstickne]

The shiftCanvas function just moves over the existing image / rendered tiles (within the same canvas) that don't need to be redrawn, in theory .. which is why it's a copy, so none of the area it is replacing will show through. The new edge tiles are then redrawn later, which is what results in a good bit of speed-up from the previous 2.1.3 version.

Because of this I'm confused that it appeares invisible (black?) after the change except for the redrawn edges. With the linked update the 'copy' operation should be set once and I don't think it is changed; unless perhaps there is an odd PIXI interaction so I would have expected the same results (it may also be save/load state that somehow allowed it to half-work with the flicker instead of not being shown at all). Even with a different composition mode selected, I really would not expect the result to be "nothing".

It makes me think that perhaps Safari might not be able to have overlapping source/destination regions in this case. I'll dig up the code (to-morrow, evening) using the extra canvas element for the shift/copy, but .. it's buried a bit.

Unfortunately I don't have access to anything i-related, but it's good to know that it can be reproduced on those devices as well.

[photonstorm]

Hi @neurofuzzy - your jsfiddle is timing out loading the skies.png file, do you have it somewhere else so I can test this on my Mac please?

[ardell]

@photonstorm I'm having the same issue here: http://ardell.github.io/ski-game/

[lastnightsparty]

I seem to be having the same issues with my scrolling tilemap disappearing only in Safari and all IOS devices. Here is my prototype for testing purposes:

http://www.lastnightsparty.com/farmlife/

Thanks for any help here!

[photonstorm]

Hi guys - just to say that I can confirm this bug on Safari / iOS. Looking into it now. The second it tries to scroll it blanks out.

[photonstorm]

Very strange. @neurofuzzy is absolutely right. This line kills it:

context.globalCompositeOperation = 'copy';

Yet Safari supports the copy operation just fine. But in this situation it dies big time. There's no console error, it's not a crash, it just blacks out. Which leads me to conclude the issue is when the copy is using the same target and destination, as it doesn't manifest if they're different.

[photonstorm]

From the Apple Safari site:

"copy—Display the source image wherever it is opaque or translucent. Display the destination image only where the source image is transparent."

I'm thinking this is basically cancelling each other out.

[photonstorm]

@pnstickne what's the immediate implications of not using copy ?

[lastnightsparty]

I can say that removing the 'copy' line doesn't work for me. It glitches the tiles (so that they look like they're melting).

[photonstorm]

Do you have multiple layers? I have just 1 layer and it looked fine by removing the line, but I'm guessing more than one layer may get messed up?