I am working on a design tool using SVG. Any other vector formats will be converted to SVG and rendered on the browser with svg.js
I started seeing delays while dragging and moving the elements, when the number of elements increased.
Are there any ways in which I can improve the SVG performance on the browser?
Also, I want give user the ability to rotate and scale elements, render clip arts and add text. Will this make the performance worse?
example
You can see that the drag is pretty slow on that element
Related
Problem
I was planning on using SVG as an infinite canvas on which I can move around using viewBox.
Turns out that when the viewbox reaches a specific sweetspot, the shapes start disappearing.
Example
Watch how the shapes always stay inside of the view box, until the viewbox passes the sweetspot:
Live reproduction
It's as if SVG has a limitation mismatch where the viewbox can keep running freely, but shapes can only render within specific bounds.
Research
Furthermore, the sweetspot is different between browsers:
On Chrome it's 33554399.
On Firefox it's 17895590.
The same happens on the other direction. Apply a minus sign to the above values and the shapes disappear on the other side of the canvas.
My best guess is that the browser implementation of SVG is internally constrained by something parallel to Number.MAX_VALUE (but is significantly lower).
However, I couldn't find any relevant documentation on the subject.
Question
Any way to fix or work around this? I'm hoping to keep my current implementation and not simulate the viewbox on my own.
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.
We currently have a screen reaching about 10000 shapes. We are allowing users to pan and zoom to explore. I thought of a couple optimizations to keep using svg in the mid-term:
culling shapes not on screen (only writing objects in our viewport to the DOM)
reducing edges when zoomed out
These 2 tactics go hand in hand; however, I was wondering if shapes not already on screen are already culled and not "drawn" by most browser vendors. If not, is it presumably better maintain a quad tree of objects in the scene and render the current set of trees that intersect with our viewport?
Yes, Firefox since version 17 has culled shapes that can't be seen. The code creates what is called a display list of things that it intends to draw. I imagine sure Chrome and IE use some similar mechanism so you'd only make things slower if you try to handle it yourself.
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.
If I wanted to build a simple game (snake, checkers, pacman or whatever) what would be the better approach - SVG or Canvas ?
Things I'm interested in:
Ease of implementation (learning curve of Canvas vs SVG) . For example if SVG has significantly less tutorials and community support that's crucial to me.
Performance (not critical to me but still important)
And also , in the gaming field , are there specific games that SVG is more suited for than Canvas (or vice versa?)
Games that require a lot of mouse interaction and not much continuous animation (such as checkers or chess, or any board game for that matter) are better suited for SVG because you work with dom elements. Consider a simple button hover, in SVG you can add event listeners or even just place g.button:hover path {fill: blue;} in your CSS and it will work. Canvas, on the other hand, requires keeping track of the hit area and drawing everything in Javascript.
Snake and Pacman would be better suited for canvas, you control everything with your keyboard and painting to canvas is less expensive than moving elements around in SVG. There are excellent gaming libraries for canvas, impact.js is one of them.
Addressing your points:
Ease of use: if you are familiar with pure javascript DOM manipulation SVG is a breeze. If you are blank slate I'd say canvas is easier to grasp, as you just paint on it.
Community support: for gaming canvas wins hands down. There is a strong SVG community but not in the gaming area.
Performance: Mixed. Both canvas and SVG can be slow if you don't pull off a couple of tricks. For example, moving a single square from left to right can be jerky in canvas if you repaint the entire screen on each frame. If you just repaint the area that changed then it's smooth. SVG would handle this case without a hitch. But on the other hand, if you want to animate thousands of rectangles at once, canvas handles it smoothly and SVG bogs down if you don't wrap the rects in a group and move the group around.
All in all, if you want to explore gaming in javascript perhaps Canvas is a better option. I've done three games in SVG, the latest one being http://color.method.ac, but I've dabbled in canvas and I think it's better suited for gaming.