So I'm building large size site, which uses css3 transitions for animations (I'm using jaquery.transit to manipulate element transitions and their css styles). And I stumbled upon 2 problems:
FF (latest update) doesn't use GPU for translate3d() layer rendering, maybe I'm wrong and mozilla doesn't use GPU accelerated graphics at all. I really don't understand that completely yet.
Even if I trick for example Chrome in using GPU for translate3d() and translateZ() layer rendering, on computers with bad GPU or with no GPU those graphics are so terrible you sometimes can't even see middle of transition just start and end.
Questions:
What do I do to improve FPS for transitioning elements, e.g. I have 3200x3200 div rotating and scaling and translating in x,y axis at same time, with approx. 5-20 elements displayed on that div's surface?
Maybe there is a way I can detect if browser has enough GPU support to know if I need to redirect to simpler version of site or not?
Because WebGL uses GPU, the amazing Modernizr project permits to check that for webGL supported browsers: http://modernizr.com/news/
Check Modernizr.webgl under http://modernizr.com/docs/
The main issue at the time was that all of the PNG's on the screen had to recalculated and recompiled in the browser.
There were several things I had to do to to maximize performance:
Always have predefined width and height attributes on images. What this does is let's the browser know what size the picture should be and when used together with scale() it won't recalculate and recompile those images. These things were very expensive. So basically if nothing else than scale() modified image size, everything was perfect and animations were awesome.
Wherever possible avoid using visibility property, it literally acts like opacity: 0 keeping the element in the layout making layout recalculation much longer. Always where possible use display: none, this will completely eliminate element from the layout calculations. This was a major pitfall, because I had to re-think the UI to exclude visibility and I had to minimize used DOM node count.
Overall it was a huge adventure and big experience, hope this question/answer helps someone.
Related
I've just started out with SVG and have gathered enough information to see that animating these objects is not the same as animating canvas objects. With canvas objects, the canvas is redrawn on every frame, but it seems like with SVG you aren't supposed to be thinking in terms of frames and FPS, but rather in terms of seconds and delays by using the built in <animate> tag.
While I appreciate all the out of the box functionality for SVG animations, I've built up quite an understanding (and library) for how to get my animations working together on canvas using the frames and a timeline paradigm.
I know there is timeline and scheduling support for SVG with libraries like GSAP or SVG.js but I much prefer thinking in terms of FPS and and frameCount.
I was wondering if I might be able to continue using this paradigm, but instead simply update the attributes of my SVG objects on each frame iteration and let the DOM re-render the positions instead of figuring out a way to describe the animation in the <animate> tag.
I'm completely open to suggestions if using the <animate> tag isn't as finicky as I think it is for scheduling my animations/getting them to move together and any suggestions would be much appreciated.
My animation needs aren't to the likes of high performance websites, I just want to step through them to show people some math concepts as they progress.
Updating SVG element attributes is a completely fine way to go about animating them. It can be more performant than clearing all elements in your main SVG tag, and redrawing - but that depends on the drawing, browser, and animation details. But, SVG renders surprisingly quickly, so if you are just stepping through tailored frames to demonstrate a concept, and if it would be more convenient to think of each frame independently, you should be completely fine to also clear and redraw. If your project is intended for a website, make sure to test your implementation on Chrome and Firefox at least as they have slight differences.
I am using javascript svg-pan-zoom.js (https://github.com/ariutta/svg-pan-zoom) libary to zoom and pan svg in web application. Zooming in Firefox is very slow and laggy, while zooming in Chrome and IE11 works very well (tested with 5MB .svg file that presents floor plan - if file is smaller, this issue is not that noticeable). Panning is working fine. I've read many topics on this issue on forum but I haven't find any solution yet. Does anybody know what is causing this problem and how to fix it?
Example: http://jsfiddle.net/coz3fd0L/3/
Check your refreshRate option. Maybe you set a high number.
If not then you may set a low number (ex. 10 which means max 10 frames per second) and if may improve your problem.
Other than that I don't know of any other problems in svg-pan-zoom. At least if pan is smooth then zoom should be the same.
Maybe your SVG has a lot of edges/curves/nodes and Firefox is simply bad at resizing such things. Or it is bad at resizing large SVGs when matrix transform is used (matrix transform is used for zoom/pan in svg-pan-zoom).
Update: From what I see this is purely a Firefox problem (or the way it is). Just opening the SVG from your example http://imgh.us/test_51.svg takes 100% of CPU (for page scroll).
Also I did try to change matrix transform values manually (to test if it is svg-pan-zoom issue) and it is anyway very slow.
The only solution I see is to try to optimize your SVGs (maybe it is possible to make them simpler: less edges, nodes, do not render white elements...).
I am planning on creating a real-time multiplayer platformer game in HTML5 using javascript. After searching about 4 hours on the webs, i couldn't find an up-to-date answer on the eternal question: rendering my game with DOM will be faster than rendering it inside a canvas? The game will be the whole document. 2/4 players will be jumping on the map and will shoot at each other, bombs will explode. So? What will it be. I remember I made 2 years ago a draw application with DOM and it worked kinda smoothly, but i guess canvas speed is better nowadays? Thank you guys.
P.S. I think of using Dart too.
I use canvas, and would say to do the same since it's a direct drawing mode. However, you should absolutely make sure it is forced into hardware acceleration wherever possible. You do this by setting the style of the <canvas> element into transform:translateZ(0); (or different browser interpretations of that, e.g. -webkit-transform:translateZ(0);). Manipulating the DOM can be slow now that canvas is closer and closer to native code, especially with simple methods to get the most performance out of it.
My games seem to do pretty well on different platforms with this - not universally well on every single platform (older Android OSes lag, but their JS & browser rendering engines weren't that fast to begin with), but quite well on many platforms.
Canvas is the best choice for the type of game you are describing, but some DOM elements are still very useful even using canvas, for example, asking the player's name, or creating a menú or profile section inside the game. You can render a div with absolute position on top of your canvas when you need to display DOM elements, and do all the "game stuff" like drawing and animate sprites in the canvas element.
The reason why Canvas is the best choice is simple. I'm pretty sure that you can't or it would be really hard to do things like this without the canvas element:
http://galloman.github.io/ss2d/samples/skeletons2.html
More at: http://ss2d.wordpress.com/support/
The 2nd part of the question is, which javascript library is better/easier to manipulate images with? I won't be actually drawing any shapes or anything. Other info: I'll be using jQuery and don't need to support all browsers, just webkit.
Edit:
More information: the current design is to layout/draw several rows/columns of images in a grid-like layout, with the image in the center being in "focus" (a little larger, with a border or something and some text next to it). The tricky thing is that we want the whole canvas of images to appear to slide/glide over to bring another random image into focus. So obviously the number of images in this grid needs to exceed what is visible in the viewport so that when the transition occurs there are always images occupying the canvas. Other than moving the images around, I won't be blurring them or otherwise modifying them. Eventually we will add user interactions like clicking/touching on a visible image to bring it to focus manually.
Let me know if this is not clear or still confusing.
I ran across scripty2 which seems like an alternative to using canvas/SVG for my purposes. I also started farting around with EaselJS last night, and it seems like this might work, but I'm wondering if it'll end up being more work/complex than just using standard HTML/CSS and a tool like Scripty2 to aid with animations and click/touch events. Just looking for any suggestions. Thanks!
The answer depends on your manipulation and animation.
If it's just translations, CSS wins for speed compared to canvas. I haven't tested, but I feel confident it easily beats SVG for the same sort of thing.
If you're going to be doing non-affine transformations or otherwise messing with the images (e.g. blurring them) you clearly want Canvas.
If you need event handlers per object, you clearly want a retained-mode drawing system like SVG or HTML+CSS. I haven't done enough CSS3 transforms to say how they compare in terms of speed to SVG, but they clearly do not have the robust transformation DOM of SVG.
This is a rather subjective question (or suite of questions) and you haven't yet given sufficient information for a clear answer to be possible.
I'm developing a site which has a flash background playing a small video loop scaled to fill the whole background. Over the top I have a number of HTML elements which are animated using javascript. The problem I am having is that (predominantly in FF, but also in others to a lesser degree) the flash seems to be causing my javascript animations to run rather jerky, and in some cases missing the animation altogether and just jumping to the end state.
Does anybody have any thoughts on how to make the 2 work together nicely?
Many thanks
Matt
You'll notice the same effect on BBC Iplayer - if you've played a few videos, then use the left and right scroller. The javascript animation is no longer smooth.
The is more noticeable in FF.
Chrome creates an entirely separate process for the flash, and therefore smoother, Safari is quite lightweight therefore smoother at times.
Bit of a bugger really - the only thing I can suggest is ensure your swf is optimised for CPU - if it contains lots of code, ensure you doing good memory management.
I had the same trouble once and I targeted FP10 - this offset a lot of visual work off the CPU (therefore the current process in the browser) and gave it to the GPU.
--
Aside from this, you're pretty much at the mercy of how powerful the clients machine is.
Additional for my answer above:
Thanks Glycerine. Do you think there would be any performance improvements if it was compressed into an older format? Or even just a SWF? There is no audio, so it's just an animated background really. – - Matt Brailsford
I think a newer format would be better - if you can do FP10, then again, you'll be able to utilise the user GPU, if your working in CS3, best to go for FP9.5.
Ensure your stage objects are cached for bitmap if your using large vectors
http://www.adobe.com/devnet/flash/articles/bitmap_caching_print.html
This ensures any heavy animation (even animation we regard as light) will run smoother because there turned into pixel data as opposed to complicated vector information. Its a small fix but it may work.
Try and target the AS3 engine as well. Even if your not using code. I keep saying it runs better than the as2, as1 engine with arguments from people but I'm sure you'll find your favourite camp.
If you have very large images scaled down, use a smaller form factor by photoshoping then to a smaller size. This will not only improve rendering speeds, but also swf file size.
Try those.