In QML I have multiple ways of including animations. Within others there are
AnimatedImage
AnimatedSprite
which both seem to be of similar use. With the right tools, it is quite easy to transform a sprite sheet into an animated gif or MNG file which could be handled by an AnimatedImage. The other way around is not that much harder.
In the documentation of Sprite they say:
The sprite engine internally copies and cuts up images to fit in an easier to read internal format, which leads to some graphics memory limitations. Because it requires all the sprites for a single engine to be in the same texture, attempting to load many different animations can run into texture memory limits on embedded devices. In these situations, a warning will be output to the console containing the maximum texture size.
On the other hand, the AnimatedImage usually caches the single frames, especially when the animation should loop, (which might also bring the maximum texture size to risk?)
I know that the Sprite has some fancy state machine and stuff, but the AnimatedSprite seems to be stripped of this.
As the production of content for either of those is the same work, I want to know if one of them is superior in any usecase, or whether their usecases and their performance are just entirely the same and which one to use is a question of flavour.
Actually I did not find a single reference that mentioned both in the same context...
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.
Assuming that the SVG is the standard for still vector images, there is an equivalent for animated vector-based images too ?
The problem I'm trying to solve can't be solved by pixel-based formats such as APNG or GIF, they don't scale at all on different displays, and they also get really really heavy pretty quick, vector images are what I need but I need a standard way to provide a file with an animated vector entities in it.
To be clear I'm not trying to animate a webpage or part of it, I'm asking for a filetype or standard that is good for just this task.
You can animate SVG graphics... they don't have to be static. That said, SVG is the only vector graphics format the web supports (natively) so I guess the answer is SVG! ;-)
The SVG specification includes SMIL as an animation mechanism. IE9/10/11 do not support SMIL, although other UAs do. There's a javascript library called fakesmile that can enable SMIL on UAs for which support is lacking.
There's also CSS animations which IE does support, although overall support for CSS animations is somewhat less complete in most UAs.
We are currently using PNGs in production for icons, but as a designer I'm trying to push for using SVG's for the benefit of:
a. Rendering on Retina.
b. Visually impaired users that zoom in.
c. An easier workflow when creating icons.
Are there any researches that compares the 3 methods? (PNG Sprite vs SVG sprite vs Icon fonts) in terms of performance?
If not, what and how would you compare them? (For example, I heard SVG requires more CPU power, and I have no idea how to test it or what are the consequences).
Thanks a lot! You are an amazing community.
BTW, this is what I could find:
svgs are cool, but icon fonts are just 10% of their file size
SVG + Icon Fonts:
Iconserving - SVG or Webfont?
Ten reasons we switched from an icon font to SVG
Not an answer but it will be not readable in comments
PNG's are raster images
So for render they just need to be decompressed which need CPU power but nowdays is this not so bad.
SVG's are vector XML files
Which means that you need to:
read XML text
decode it to some vector graphic capable engine/class
render vector graphics based image
Complicated SVG's (>300MB vector utf-8) have load/decode/render times even in minutes on fast machines (if decoded everything). If you decode just the basics you can do the same in seconds, but lost advanced features.
Many will not agree with this: 'problem is there is not a single 100% compatible easy to implement SVG library ... at least that I know of' but take in mind I do not use frameworks or environments for WEB like JAVA or PHP ... Also each SVG lib has it own quirks. If you compare rendered SVG between different web or image viewers then it is not the same and many features aren't supported everywhere.
You can code your own SVG decoder but it is bit complicated. If you want just basic functionality like path and shapes without animations or gradients then it is relatively easy to do, but if you want to implement everything you would spend a lot of time with that.
For a time I had a big problem finding good free SVG editor. The only one 'usable' I found was Inkspace but it is slow and a bit user unfriendly for my taste. On the other hand it can open almost every type of SVG I use in the right way...
[Notes]
If you want to use SVG's for icons I strongly recommend to render them to raster on App start and then use just raster images like bitmaps from memory to avoid performance problems.
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.