HTML5 buffering...?
Monkey Targets Forums/HTML5/HTML5 buffering...?
| ||
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? |
| ||
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. |
| ||
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. |
| ||
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 |
| ||
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! :) |
| ||
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). |
| ||
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. |
| ||
@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 :) |
| ||
Has anyone else tried this target? Should I post it on the 'user targets' forum? |
| ||
I tried it. In firefox on the desktop it runs more smooth. On mobile, it didn't help so far. |
| ||
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. |
| ||
In Safari for Windows HTML5 is faster and smooth than Fast_HTML5 |
| ||
--nvm |
| ||
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. |
| ||
I found that with command SetBlend AdditiveBlend Firefox gens 3-4 fps only without it or with SetBlend AlphaBlend 60-70 fps |
| ||
Must be the browsers slowing down are those implementing doble buffering behind the scenes. |
| ||
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() |
| ||
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? |
| ||
rIKmAN wrote: Any ideas? Needs some changes to new html5 target templates |
| ||
If you are developing html5 for mobile I wouldn't recommend using double buffering. |
| ||
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. |
| ||
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. |