my question may seems not new, but as far as I searched for days I couldn't find my answer.
I'm trying to make a webpage with PIXI.js which uses webGL.
My webpage is mouse movement parallax, I mean all the movements an object can have is few pixels when the user moves his/her mouse pointer.
Now my problem: I have some simple images and i don't know to use svg or png.
My images are like these:
https://1drv.ms/i/s!Aj-BeFYyTnRzhTBSVEXXeJ2c-O7V
https://1drv.ms/i/s!Aj-BeFYyTnRzhTFeTzJLrWaq_VFh
https://1drv.ms/i/s!Aj-BeFYyTnRzhTIa9lAaS9dKX1DL
I want to make my webpage as smooth as possible and I don't know to use png or svg. I searched a lot, some says it depends on the png and svg, in my case my svgs won't be too complex but some says because svg use CPU and the WebGL use GPU using them both, cause lack of performance, and also some says which using svg in PIXI makes no difference than the png because PIXI makes texure from them and there won't be any deference...
I'm new to webGL and Pixi so now with these answers I became confused, by the way, for my case the images size is not mattered, I only wanted as much smoothness as possible.
thanks a lot for your help.
It doesn't make a difference for runtime performance, the SVGs will be rasterized into textures either way. However during initialization where the browser neeeds to rasterize the SVGs to create a texture from them there might be a significant performance penalty depending on how complex your SVGs are.
However since you're developing for the web aforementioned penalty is easily offset by the fact that you're loading the SVGs from a server which introduces way more latency than rasterizing the SVG will, even more so if you consider the size difference between a rasterized PNG and a SVG(assuming you're not planning to create tiny textures from them).
So final verdict, go with SVG, its lossless and small aswell as resizable and editable from within client code. It also saves you from exporting your source assets to PNG everytime you change something.
I am building a web application which will display a large number of image thumbnails as a 3D cloud and provide the ability to click on individual images to launch a large view. I have successfully done this in CSS3D using three.js by creating a THREE.CSS3DObject for each thumbnail and then append the thumbnail as an svg:image.
It works great for upto ~1200 thumbnails and then performance starts to drop off (very low FPS and long load time). By the time you hit 2500 thumbnails it is unusable. Ideally I want to work with over 10k thumbnails.
From what I can tell I would be able to achieve the same result by creating each thumbnail as a WebGL mesh with texture. I am a beginner with three.js though, so before I put in the effort I was hoping for guidance on whether I can expect performance to be better or am I just asking too much of 3D in the browser?
As far as rendering goes, CSS3 should be relatively okay for rendering quite big amount of "sprites". But 10k would probably be too much.
WebGL would probably be a better option though. You could also take care about further optimizations, storing thumbnails in atlas texture or such...
But rendering is just one part. Event handling can be serious bottleneck if not handled carefully.
I don't know how you're handling mouse clock event and transition towards fullsize image, but attaching event listener to each of 2.5k+ objects probably isn't a good choice anyway. With pure WebGL you could use imagespace for detecting clicked object. Encoding each tile with different id/color and using that to determine what's clicked. I imagine that WebGL/CSS3D combo could use this approach as well.
To answer question, WebGL should handle 10k fine. Maybe you'll need to think about some perf optimization if your rectangles are big and they take a significant amount on the screen, but there are ways around it if that problem appears.
I have a website with 3 full screen background images that use a custom parallax scrolling script utilizing requestAnimationFrame and transform:translate3d() for its animation. I did this because after a fair amount of research on the subject of visual performance this was the best alternative then using canvas.
My problem is that my page runs very smooth on Firefox 29.1 (*because it is most definitely using the computers GPU to render the page and composite layers) however for some reason, Chrome is has some major bottlenecks.
I am getting tremendous performance spikes (way less then 30fps) when I scroll down my page... but an interesting thing I noticed was that it happens specifically just as one of the background images that is being animated with the script (set as background-position:cover) enters into the viewport.
There is a repaint operation happening because the background image is being resized to fit the viewport width/height and that is causing a tremendous performance hit. Considering that the gpu isnt working correctly for my Chrome, but also that I would like to make my page perform super silky smooth when scrolling even without hardware acceleration, is there a method of preloading images/frames and having them already resized before they are scrolled onto screen? Like a frame buffering technique to ensure all the calculations and resizing is finished well before a user scrolls to that image on screen?
In a design that I'm working on, there is a recurring image background shape that appears several times in different sizes throughout the site. For example, one page uses it as a huge background images, where the top and bottom part of this image is cut off by the browser edges.
It's not an easy pattern to create with canvas, but as far as I know it's possible. Here's what it looks like.
Am I better off making several images of this same pattern or is this background image easy to recreate through canvas? If it is appropriate for canvas, how do I go about recreating it in the various sizes? I wish I knew how to begin something like this using canvas but it's above my skillset.
I've converted your shape to an SVG shape here: https://gist.github.com/1321653 — use it as you'd like.
According to caniuse.com, SVG is supported on all common browsers except for IE8 and earlier.
For IE8 and earlier you might be able to combine canvg, a SVG-to-canvas library, with explorercanvas, a canvas emulator for IE8 and earlier. Or you could display a rectangle with a background color — IE users might not miss the splat.
Edit: You could also get creative with CSS3 background gradients, ala http://www.ecsspert.com/ (famous logos created with only CSS), but compatibility is low across browsers.
I'm planning on writing a game using javascript / canvas and I just had 1 question: What kind of performance considerations should I think about in regards to loading images vs just drawing using canvas' methods. Because my game will be using very simple geometry for the art (circles, squares, lines), either method will be easy to use. I also plan to implement a simple particle engine in the game, so I want to be able to draw lots of small objects without much of a performance hit.
Thoughts?
If you're drawing simple shapes with solid fills then drawing them procedurally is the best method for you.
If you're drawing more detailed entities with strokes, gradient fills and other performance sensitive make-up you'd be better off using image sprites. Generating graphics procedurally is not always efficient.
It is possible to get away with a mix of both. Draw graphical entities procedurally on the canvas once as your application starts up. After that you can reuse the same sprites by painting copies of them instead of generating the same drop-shadow, gradient and strokes repeatedly.
If you do choose to draw sprites you should read some of the tips and optimization techniques on this thread.
My personal suggestion is to just draw shapes. I've learned that if you're going to use images instead, then the more you use the slower things get, and the more likely you'll end up needing to do off-screen rendering.
This article discusses the subject and has several tests to benchmark the differences.
Conculsions
In brief — Canvas likes small size of canvas and DOM likes working with few elements (although DOM in Firefox is so slow that it's not always true).
And if you are planing to use particles I thought that you might want to take a look to Doodle-js.
Image loading out of the cache is faster than generating it / loading it from the original resource. But then you have to preload the images, so they get into the cache.
It really depends on the type of graphics you'll use, so I suggest you implement the easiest solution and solve the performance problems as they appear.
Generally I would expect copying a bitmap (drawing an image) to get faster compared to recreating it from primitives, as the complexity of the image gets higher.
That is drawing a couple of squares per scene should need about the same time using either method, but a complex image will be faster to copy from a bitmap.
As with most gaming considerations, you may want to look at what you need to do, and use a mixture of both.
For example, if you are using a background image, then loading the bitmap makes sense, especially if you will crop it to fit in the canvas, but if you are making something that is dynamic then you will need to using the drawing API.
If you target IE9 and FF4, for example, then on Windows you should get some good performance from drawing as they are taking advantage of the graphics card, but, for more general browsers you will want to perhaps look at using sprites, which will either be images you draw as part of the initialization and move, or load bitmapped images.
It would help to know what type of game you are looking at, how dynamic the graphics will need to be, how large the bitmapped images would be, what type of framerate you are hoping for.
The landscape is changing with each browser release. I suggest following the HTML5 Games initiative that Facebook has started, and the jsGameBench test suite. They cover a wide range of approaches from Canvas to DOM to CSS transforms, and their performance pros and cons.
http://developers.facebook.com/blog/post/454
http://developers.facebook.com/blog/archive
https://github.com/facebook/jsgamebench
If you are just drawing simple geometry objects you can also use divs. They can be circles, squares and lines in a few CSS lines, you can position them wherever you want and almost all browser support the styles (you may have some problems with mobile devices using Opera Mini or old Android Browser versions and, of course with IE7-) but there wouldn't be almost any performance hit.