SVG Performance testing

hmmm crap i edited and graphics dissapeared :(

FYI once SVG rasterization is complete, SVG Picture draws exactly like a Sprite. The performance difference probably only comes from SVG Picture calculating if it needs to rasterize the SVG larger if the object is being displayed bigger (which it won't if everything stays the same size, but it still has to check).

try check the proyect i shared, i used a small svg file and tryed to make it in the same size. i dont know how the calculation for resize works, isn't a vector just a coordinate point and resizing adding the diference? why is souch a big difference in performance?

i found that the svg file takes some time to load using the action "change image", there should be a "load complete" event for the svg to be ready to show or it will be transparent until that.

I did actually find an accidental performance pitfall when rendering large numbers of SVG Picture instances. I've fixed it for the next release - according to my measurements it makes it ~6x faster.

wow!! i want to try that

Testing with the update, the good part is that in idle mode the svg population IS OVER 9000! it almost doubled the previus test (5500)

But in motion and action there were not much difference, it still having a mayor drop on FPS when hitting a wall, and if the FPS count goes down, all the svg doesnt stop on solid objects

so i trayed something harder, an X with line and color, the good thing was that the svg population didn't went down too much, it still over 9k

BUT

There was a crash

The console log messages don't indicate a crash, just that it's slow.

Coming up with good tests is difficult, I'd advise just replacing sprite with SVG Picture in one of the official tests, which is what I did with the quad issue performance test to measure a ~6x improvement. That test is focused on the drawing performance - the bounding box test is mainly about recomputing rotated boxes, which works the same regardless of the object, so will obscure the real results.

The console log messages don't indicate a crash, just that it's slow.

Coming up with good tests is difficult, I'd advise just replacing sprite with SVG Picture in one of the official tests, which is what I did with the quad issue performance test to measure a ~6x improvement. That test is focused on the drawing performance - the bounding box test is mainly about recomputing rotated boxes, which works the same regardless of the object, so will obscure the real results.

i realized it wasnt tilt, it was playing at 1fps, i think the cause is that i pushed to the left and the fps drop made all objects to get inside the solid object (the black wall) since they were bound to layout and the wall was at the border, so they never came out of it and stuck at 1fps.

i tryed to measure response and reaction, i mean how long takes the objects to recive the signal, since i had previously problems with joystick-game lag,

and reaction to actions, to discover the problems, like when objects collide for example, like in this case the svg objects tends to jump walls or get inside unwanted things, making that kind of fps killing bug.

I think what i did in this is a general gaming benchmark: Controler, Movement, Collisions and Drawing, and their CPU and GPU demand (usefull to find minimal platform requeriments)

the last test makes me question, is there a way to delegate some cpu work to the gpu? gpu is not getting close to 10% in the worst scenario (even in a smaller gpu, like a bluberry pi 3, i never saw use of its power) svg should be using more or less of it but it is not different to a sprite.

I'm not clear what you're testing any more. Are you now looking in to intensive collision benchmarks or something? That doesn't sound specific to SVG Picture in any way.

just testing in the last one, intensive collisions and signal that's right.

i want to make a big tower defense with as many litle enemies as i can so i test how the engine will behave with so many things having orders and colliding.

what i mean in the last post is that i didnt find any difference to the gpu and cpu use in svg or sprites (at least with this kind of test) and wonder if there is a way to take more juice from the gpu and less from the cpu, i dont know.

Collisions have nothing to do with SVG or the GPU. So I'm still confused as to what you're testing or asking about.

FYI once SVG rasterization is complete, SVG Picture draws exactly like a Sprite. The performance difference probably only comes from SVG Picture calculating if it needs to rasterize the SVG larger if the object is being displayed bigger (which it won't if everything stays the same size, but it still has to check).

Does this mean that we can improve performance if the svg file size is the same as the svg object? My svg files are 28x28 in size but my objects are 180 x 180. So does this change in size increase the time for rasterization?

It probably has no effect at all. You can run your own performance tests and try to measure the difference if you really want to know.