HTML5 and Canvas scrolling: trick interesting or useless?

Question

I've already read all the stuff around scrolling:

Structuring an HTML5 Canvas/JS Game

and so on:

• HTML5 Canvas tutorial
• The secret to silky smooth JavaScript animation
• Google search "HTML5 Scrolling"
• Canvas Games
• Build a vertical scrolling shooter game with HTML5 canvas
• Math mayem
• CAAT JavaScript framework

(The latest one is impressive, but even though almost everything is done there's nothing about scrolling).

Here's what I'm thinking about, and I didn't found something valueable about that. An idea just came to my mind and I'm wondering if I should take a lot of time thinking about that and trying, or not (that's why I'm asking here actually).

I'm planning to do a game with a scrolling "à la" Mario.

The big drawback about scrolling is that you have to redraw the whole background. I've already avoided two performance problems of the sprite / scroll: create two canvas one top of each other:

• the background
• the sprites

And just erase the sprites.

The problem is about the background: I'm making a full copy of the background to the "visible" canvas. (note: there's no problem about flickering because writing in JavaScript is a blocking operation and all modern browsers handle vertical synch, so no double buffering needed).

Here's an old version of what I'm writing, but you'll get the big picture:

Test HTML5

Now I'm wondering for the scrolling: what if I do a "background div" instead of a canvas, with the appropriate CSS (background image for the background), and write the tiles on the image directly, then change CSS to simulate the scrolling? Should it be faster? If so, why? Is there any good idea out there for this?

Solution 1

My final conclusion: after many tries, including Eirk Reppen suggestion, I write directly "raw" into hidden parts of the canvas and use CSS: all webbrowsers handle already image flickering and all that stuff around, and they have already optimized everything.

So each time I've tried to "optimize", the results were worse.

It seems that webbrowsers are made to handle properly basic stuff made by beginnners... maybe because 99% of HTML content is made by beginners.

Solution 2

On a semi-modern+ computer with a semi-recent+ browser, the fastest thing to do is probably to take a super-long div with background images, set overflow to hidden and scroll by adjusting scrollLeft or scrollTop properties. This is MUCH faster than adjusting CSS properties as it shouldn't trigger any reflow calculation in the CSS engine. Basically, any time you touch a DOM property that could have CSS impact, the whole (or at least a lot of) of) the structure of the document needs to be re-checked and re-rendered.

You could load in chunks of the backgrounds as they get close to avoid the one giant massive image load. I don't believe there is any 100% surefire way to pull an image out of memory across browsers but removing references to it in the DOM or in your CSS probably doesn't hurt when you've scrolled far enough past a piece of your background. That way the browser's garbage collector at least has the option of clearing memory.

In pan-mobile solutions that rely on webviews (like Cordova/Phonegap), however, well that's why I arrived at this question.

I have no idea but I'm pretty sure mixing HTML and canvas is a lousy idea for performance purposes. Right now I've got a not-super-complicated android game choking on 50x50 100px tiles in a canvas element in an android web view that also has some basic HTML in the mix for stuff like controls and separating a couple other canvas elements from the rest. I basically have a birds-eye-view ship cruising around and doing scans with a cheesy radiating circle grahic that reveals elements on a map fog-of-war style. Works great in a browser. Complete disaster in the cordova app version.

I suspect the only way I'm going to realize my pan-mobile game dev dreams is to use one of the many openGL-wrapped-in-a-canvas-API solutions out there and completely ditch the HTML which I find damned convenient for UI implementation, given that the bulk of my experience is in web UI. Another general tip for web view HTML is to avoid scrolling within internal elements if you can (so just let the body handle overflow). Scrolling overflow in anything but the body didn't even work in Android 2's webviews and it still seemed to cause 4.1's views to choke on an earlier/simpler version of the app I'm working on.

Comments

[Olivier Pons]

"other custom ways can be better." <= that's what I'm looking for actually ;)

[ViliusL]

so if map is small, you predraw all into some cache/div/canvas and use css to move it (also hide sides). If map us huge, you can split it into some areas, and do same for each area, but you need to join these areas somehow. Or if map is 2d mainly, you can set key points where you refresh map cache for example 500m forward and 500m back. Becouse generating map on every move can be really slow.

[Olivier Pons]

The map is small, i'm doing a hack for infinite scroll, and I found out that it's much slower when I use CSS than when I do a raw copy. Strange.

[James P.]

Isn't there a way to stream map data in ?

[Olivier Pons]

For your information, I've totally given up on doing something cool in HTML5 whereas I'm actually very good in the Web development. But developping cool & all-device in one HTML thing is impossible. On the contrary, Unity give me everything I need, except the fact that I have to learn 3D maths... but really, everything else is simply incredible... and it works, it's not like the web: always "work-in-progress" (I seriously begin to be fed up with Web & JavaScript because of that).

[Erik Reppen]

If you're supporting mobile, I'm entirely sympathetic. But I blame Android more than HTML5 for that.

[Calaf]

On El Capitan, both samples you provide work fine on Safari 9.0.3, but they both crash Firefox 44.0.2. These are the most recent version of the two browsers at this time (end April 2016).

[pancake]

Hi @Calaf, I've just tested on a colleague's El Capitan and no problems with either Fiddle. He is running version 46.0 - I'm not sure why an earlier version would be crashing and can't easily test it, but I think your version is no longer supported.