A lot of things on the internet are very conflicting on how to deal with things.
Here's my situation:
I'll be building a client in javascript, using the HTML5 canvas, the canvas will contain multiple images (ranges from 20 to 5000), which will have to be drawn, they can also move (sometimes all at once).
Now I will only redraw "differences" in the screen instead of the whole screen, but still, should I pre-render the images somehow? Cases can occur where a lot of the images will be moving.
I read about pre-rendering them in an off-screen canvas, and that would help to render them again. But does that method really help me to improve the performance? I mean it is not professional at all to have a canvas for every image right?
If not, are there other good methods to help rendering everything? Or shouldn't I worry about performance?
Using multiple layers isn't an option here by the way. (actually what i described here is 1 layer of 3 already)
Kind regards
Jonas
Related
I'm getting into web animations, WebGL, Canvas, ThreeJS, GSAP and all those fun tools. I'm investigating different websites and how they're able to achieve certain effects.
I am mind blown by these two sites: https://14islands.com/ & https://www.hellomonday.com/.
Their animations look simple(ish). Liquid effect on images. I know with ThreeJS filters or WebGL or other Canvas libraries you can achieve the effects. What I don't understand is that both of these sites have a full-sized <canvas> element fixed to the background. And render almost all the images on the site through the <canvas> rather than pure HTML elements.
This allows to have all images to have really dope effects. But what I don't understand is how can they sync the positions and sizes of the images with HTML DOM elements so perfectly?
This seems like a nightmare to code. Also wouldn't it be a huge performance burden to update every image on the canvas when the user scrolls or resizes the page?
I believe I'm missing something. Perhaps there's a library that handles most of this?
If there are any simple examples, I'd love to see them.
Thank you for your time :)
Welp turns out this can be done quite simply with ThreeJS. Perhaps there are ways as well but this seems easiest to me.
TL;DR: You can create a scene for a div, and you can do this multiple times with ThreeJS so that it renders a scene within the specified div.
Demo: https://threejs.org/examples/?q=multiple#webgl_multiple_elements
Code: https://github.com/mrdoob/three.js/blob/master/examples/webgl_multiple_elements.html
I am working on a javascript canvas game and I would like to improve the performance of the game. I am reading some articles about how to achieve better performance - one technique being pre-rendering.
Does it make sense to render every object, each of which has a texture, to it's own separate canvas element? Here is an example of an entity I am rendering:
fruitless.ctx.save();
fruitless.ctx.translate(this.body.GetPosition().x,this.body.GetPosition().y);
fruitless.ctx.rotate(this.body.GetAngle());
fruitless.ctx.scale(this.scale.x, this.scale.y);
fruitless.ctx.drawImage(this.texture, ... )
this.face.draw();
fruitless.ctx.restore();
So essentially I am running the drawImage() function each iteration... Pre-rendering suggests this drawImage() should be done in the initialisation (just once) - is that right?
Hard to give specific recommendations without knowing more...but here's a start:
Put any static background elements in an html image and lay that image down first. Scroll the background image if it is static but larger than your game viewport.
Sort animated elements by when they need to animate into several groups. So sun and cloud elements that animate on frame#5 will be one group. A grape-man and raison-man that animate every frame will be in a different group. Create a canvas for each of these several groups.
Put infrequently animated elements on a sprite-sheet.
Put frequently animated elements in their own image object.
Put frequently re-textured elements in their own offscreen canvas and re-texture there. Here's the trade: canvas's operate poorly on mobile, so you don't want a lot of canvases on mobile. But pre-rendering all variations of textures into image objects takes up a lot of memory.
Bottom line:
Pre-rendering will undoubtedly give you a performance boost.
But you need to test various pre-rendering strategies to see which works best on which device
To answer this question:
Does it make sense to render every object, each of which has a texture, to it's own separate canvas element? Here is an example of an entity I am rendering:
Well, that depends. How many are there? and what are they doing?
If they're all whizzing around all the time, then you might as well keep them all on the same canvas element as, regardless, this will be consistently updated.
If some are static, group them.
Your goal is to do as few drawImage calls as possible as this is fairly expensive.
Also, talking broadly, it's a good idea to leave the micro optimisations till the end.
I'm working on a website that uses a lot of large images and a lot of javascript.
Check it out here – http://joehamilton.info/1/1/
I've been trying to improve the performance and have had little success. I would just like to keep the frame rate smooth because sometimes it gets bogged down.
I thought it might have been code that was bogging it down but after discovering profiling in chrome it seems to the "paint" process that is slowing things down.
I'm just wondering what I could do to improve things. I'm open for any suggestions but I guess I was thinking along the lines of these things types of things:
• Will compressing the image files help?
• Would a 300px square repeating pattern image be faster to paint in a 900px square div than a 900px square image..
It's a large and complex site so I would rather not spend ages modifying things if it's not going to help.
Any expert raster image people out there?
For anything moving around you should use transitions and transforms rather than jquery animate and background-position as it will then be hardware accelerated in some browsers. It also avoids repainting so regularly. http://css3.bradshawenterprises.com/demos/speed.php is an example comparing the two techniques in an admittedly extreme case.
If you can't do that, ensure your animation uses requestAnimationFrame rather than a setTimeout loop.
That should help a lot.
I have a project I'm planning which based on kind of an 'interactive world' style experience where the browsers viewport moves around to show many different graphic environments, it must all be fluid and no page-to-page breaks. The project is in js/html5/css3
The problem this poses is that the entire 'world' will be perhaps 8-15,000 px squared (it also rotates, and has various png alpha overlays on top of it)
I was going to run some tests but there are so many ways to approach this and I'm looking for the most fluid one. My knowledge of the internal workings of browser render engines isn't great so I thought I'd ask around.
I cant use the 'tiling' approach which google map uses as it's not fluid enough (too blocky) also when rotating around it's going to create headaches do the math-transforms to work out which tiles to load at what angles so here are the 2 choices I have boiled it down to:
(1) The "Huge" image approach
The benefit of this is that once it's loaded everything is easy, the downside is that it's going to be huge and I cannot show an incremental preloader as the image queue will essentially be 2 images (overlay and huge img)
(2) Image segments
The benefit is that I can show a preloader with an image queue at 10% increments (10x images)
Question:
is the 2nd approach going to have a more painful overhead on the browser's rendering engine due to there being 9 separate sets of calculations being done or do browser engines simply see them as one painted area once it's initially rendered and then update it as a whole? Or each time the dom is changed (rotated etc), the browser has to run the same transform/repaint process 9 times?
Thanks very much.
LOTS of tests later: result: Use a big image, seems to be less for the browser to deal with.
I think there are two diffrent solutions for the problem:
1) First the solution shown by aves Engine, which renders the whole game with html elements and external stylesheets e.g. CSS3 transfomations. Pro's are that the event-handling is much easier when working with div's than by rendering on canvas.
2) Like isogenicengine.com shows you could render the game on html5 canvas element. Mabye that's the better solution, because rendering on canvas is the way that millions of 2D-games were written before and in future the industry will optimize the drawing methods e.g. with hardware acceleration. At the moment the contra is that rendering on canvas is slow if you would like to render in fullscreen. If you would like to render only in a specific area of 200x200px that's okay, but in fullscreen you get stuck with a framerate of 10fps.
What do you think is the better way to create a game for the web?
Thanks for your opinion!
PS: If you have some articles about the topic please paste some links
I don't think it's a clear one size fits all kind of thing. I really think it depends on what you want to do with your game.
If you are doing a lot of vector graphic manipulation, perhaps canvas is a better choice vs engine like aves. For tiled based, maybe aves will work better.
You can render fast on fullscreen canvas if you're clever about only re-rendering dirty regions. But if your whole canvas needs to change every frame this obviously isn't going to help much.
I've spent alot of time recently looking into this issue and my conclusion is pretty simple.
Use HTML Elements, lets say that HTML5 actually makes progress and in one year the major browser support it. How long does it then take to get the general user base of the web on the latest browser (IE6 still has a choke hold in some sectors). So making the game available to as many people as possible is key! (In my mind anyways)
If however, your looking to learn and develop, go with canvas.