HTML5 buffering...?

Monkey Targets Forums/HTML5/HTML5 buffering...?

SLotman(Posted 2013) [#1]
I don't know if Monkey already do this, but this article uses an off-screen rendering, and make it sound as something too good to be true!

Any thoughts? Would this be good for html5-monkey? To speed things up? or not?


computercoder(Posted 2013) [#2]
Thats nothing more than double-buffering. This is very useful for canvases that only have a single buffer. You create one background buffer and always paint to that as things are progressing in the frame, then at the beginning or end of the frame, you flip the image to the visible buffer.

In GDI, this was absolutely neccessary, as the smoothness of the game was choppy without double-buffering. Anymore, even with GDI+, the canvases are double-buffered by default, and you no longer need to make it happen manually.

I have no idea how its done in Monkey, but it seems to me that its already incorporated with how fast animation is using it. I could be wrong :P

I say to try out testing with a single canvas and then the same code using two canvases and test it out for yourself. If there is an improvement in speed, then you know its not double-buffering. If you don't notice a speed increase, then its already handled.


SLotman(Posted 2013) [#3]
Just confirmed: Monkey does NOT use a secondary canvas to render stuff.

So it can be faster! (And believe: any speed improvement on HTML5 will always be welcome)

Edit: just got the HTML5 generated by monkey for my "Escape from Alcatraz" game, applied that thing on it, and got a speed boost. Don't know how much, but it is visible that the game is running faster.


SLotman(Posted 2013) [#4]
Ok, so I just made it a target... "Fast html5". Could you guys please test it out?

Just download, extract it on /targets, restart TED and you'll have it as a new target available.

http://www.icongames.com.br/temp/fasthtml5.zip


rIKmAN(Posted 2013) [#5]
This is awesome! :)

My game was showing quite a bit of slowdown during testing/debug using HTML5 (it's an iOS game but HTML5 is faster to test with) and I can also confirm that there is quite a noticeable speed boost using this.

It runs faster than the HTML5-GL code by devolonter, which gave a speed boost over standard HTML5 but still had slowdown.

Not sure if also using that with this double buffering would speed it up even more, but even if not - this is great work, thanks! :)


therevills(Posted 2013) [#6]
Cool! Well done Slotman!

(BTW maybe submit it as a change to Github rather than a new target, since its only a few lines of code different from the original HTML Target).


SLotman(Posted 2013) [#7]
I never used Github, so I have no idea where to start... but I think this should be tested further, to see if it's stable enough - if no problems arise from it.

(Specially since the visible canvas is called visCanvas, so for example routines that hide the mouse by finding "GameCanvas" have to be changed!)

rIKmAN: This is double buffering: not 'native' on HTML5 (I don't even think it has native double buffering), but everything now gets drawn into an invisible canvas, and in the end of the render loop, it gets copied to the visible one.


computercoder(Posted 2013) [#8]
@SLotman
Good job getting it to work (and researching it)!

@rIKmAN
This technique can also be applied to HTML-GL as you asked about. if the code doesn't already have double buffering applied its fairly simple to incorporate. It will give a nice improvemnt like SLotman noticed with just HTML :)


SLotman(Posted 2013) [#9]
Has anyone else tried this target? Should I post it on the 'user targets' forum?


MikeHart(Posted 2013) [#10]
I tried it. In firefox on the desktop it runs more smooth.
On mobile, it didn't help so far.


SLotman(Posted 2013) [#11]
I'm a bit skeptical... I took this code from another thread and did a small benchmark:



And the results I've got were very strange:

         HTML5  / Fast HTML5 (120 update rate)
firefox    50         48
chrome     60         65
IE         32         32                  

IE as expected had the worst FPS possible on both cases, and chrome the best. I set the update rate to 120 fps, so it wouldn't be stuck at 60fps on chrome.

On chrome, the fast html5 wins hands down - and also it seems to be marginally faster on IE (higher FPS spikes, but on average, same speed). Only on Firefox it lost more speed, I don't know why.

Those tests were done on Win8, 64 bits, latest versions of all browsers.


nikoniko(Posted 2014) [#12]
In Safari for Windows HTML5 is faster and smooth than Fast_HTML5


slenkar(Posted 2014) [#13]
--nvm


nikoniko(Posted 2014) [#14]
SLotman wrote:
I'm a bit skeptical... I took this code from another thread and did a small benchmark:


May be this example is not correct for test. A lot float digits when HTML5/JS likes integer values yet.
I read several topics about DB where speed is up when many sprites are drawn on the hidden canvas.


slenkar wrote:
-nvm


It works for Firefox browser and may be useful for Firefox OS target.


nikoniko(Posted 2014) [#15]
I found that with command
SetBlend AdditiveBlend


Firefox gens 3-4 fps only

without it or with
SetBlend AlphaBlend


60-70 fps


GuShh(Posted 2014) [#16]
Must be the browsers slowing down are those implementing doble buffering behind the scenes.


nikoniko(Posted 2014) [#17]
GuShh wrote:
Must be the browsers slowing down are those implementing doble buffering behind the scenes


Many developers say of browser already uses DB for canvas drawing therefore we have triple buffering with fasthtml.

Modern browsers has requestAnimationFrame() method to call internal canvas updating procedure instead settimeout()


rIKmAN(Posted 2014) [#18]
I updated Monkey last week and this target seems to have stopped working, or is it just me?

I copied over all the files from the older (working) version, but I'm getting the following error when I try to compile anything..
Monkey Runtime Error : TypeError: Cannot read property 'call' of undefined


Any ideas?


nikoniko(Posted 2014) [#19]
rIKmAN wrote:
Any ideas?


Needs some changes to new html5 target templates


FelipeA(Posted 2014) [#20]
If you are developing html5 for mobile I wouldn't recommend using double buffering.


nikoniko(Posted 2014) [#21]
ilovepixel wrote:
If you are developing html5 for mobile I wouldn't recommend using double buffering.


Pre-render content or part-of-scene rendering may help for speed up mobile html5 app.


FelipeA(Posted 2014) [#22]
From my experience, pre-rendering things like text and static things is good for speed, but having an off-screen canvas and rendering everything there, and then rendering to the on-screen one is not. On some browsers it could look as an improvement on performance, but not for mobile browsers. I've been working a lot on mobile html5 development and doing this would decrease performance up to 40%. Right now I don't have an answer for why this happens, but from a lot of testing that's what our team got as conclusion.