I've been tweaking with things and I wanted a good benchmark for speed, so I took to drawing things. Here are the results. The numbers are the amount of items drawn before the FPS dips below 60. I eyeballed them, so it's not "scientific" by any means, but it should show you the general trend, at the very least.
+--------+------+-------+-------+
|Version | Game | Draw | Cull |
+--------+------+-------+-------+
|v1.5 32 | 3300 | 7400 | 6400 |
|v1.5 GL | 4000 | 8800 | 7000 |
|v1.6 32 | 6000 | 11000 | 12000 |
|SSFML | 7000 | 8600 | 14200 |
+--------+------+-------+-------+
Game: A test in which items are drawn in a game environment (separate update and render loops).
Draw: Items are drawn on screen and stay on screen (single update/render loop).
Cull: Same as draw, but items allowed to leave screen.
It turns out SSFML has really good culling, but in the end of the day is no faster than a
software driver. WTF? I think hardware acceleration isn't that fast. In fact I think it has to do with Sphere's API. Because you can't do a lot of tricks in Sphere, you nerf the maximum potential that "hardware acceleration" gives you. You have an API such that you draw things in order as they appear, so sprite batching is harder to achieve. You have methods like blit() and blitMask(). And you can't tell Sphere to put things into texture atlases. I could get away with fonts, but not for general images. So Sphere forces you to use unique textures each time something is drawn to screen, caising many GL state changes and making it perform not as fast.
In a general game environment, SSFML it is faster, but it has to do with both culling and the fact, generally, the JS executes faster so game calculations happen faster. Yes, the JS environment can be more of a bottleneck than rendering in Sphere, and obviously, it shows.
But I do have an idea. SSFML could generate atlases for you behind-the-scenes. It
might be possible to cache all loaded textures into a giant texture. If that giant texture is filled up, it then creates another giant texture to use. An image, behind the scenes, then only encodes where it's base texture is, and what atlas to use. This might just work.
I did implement a sprite batch, but at the end of the day, it drew things out of order, and was only like 15% faster (if you were lucky and it happened to draw everything in the same order you blitted them in).