SVG Performance testing

  • I love vectors so i started to test the SVG performance.

    Using the

    Bounding box updates performance test

    but with real deal testing, since i belive that pure raw cpu utilization is quite useless for a game. Then i added 3 things:

    - 8 movement behaviour

    - solid walls to hit

    - and bound to layout

    The results in 2 phases:

    First, raw draw Sprites

    12815 objects

    raw draw svg

    5529 objects

    The result is a litle bit obvious, sprites double svg in screen quantity. but now i cap the sprites to a same amount of elements and added movement

    using the keyboard i move everything to the top so they collide. And there is an intresting performance test, with the sprites we get 60fps in stand,18-24 in movement and 10-14 fps on collision with the walls.

    in svg we have 35 fps in stand, 22-23 in movement and a weird spread from 8-20 in collision, having issues when drops the 10fps barrier, as you can see they jump the wall :P

    im pretty sure that with time this will be fixed and better. For now i just hope for the momment when we can edit the xml data in runtime to create animations (like rotating objects or editing the xml variables like the color of the vector elements)

    the proyect for testing drive.google.com/open

    Tagged:

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)