Closed sansumbrella closed 9 years ago
It's true. On OS X this ended up being a pretty bad example of why you'd want to render to texture. I really should have used the pony SVG or something more complex. On iOS, though the proxies end up being slightly faster; 60fps vs 40 or so.
Also, proxies will get less efficient as you increase the shape count due to the cost of rebinding textures. In that case you'd want a texture atlas or something.. but that's a little too involved for sample code.
BTW, Do you happen to know a C/C++ library that performs dynamic incremental texture atlas allocation? :wink:
Oh boy, that would be really nice to have. It would be pretty easy (though potentially wasteful) if you required square allocations.
Wrote something kind of like that for SelfieSelfie called GridTexture.
But once you're out of space, it just wraps around. The part that I think would be most annoying is atlasing across multiple textures. Since then you would need to order your draws to avoid swapping between all the textures.
This is a great wrapper! The shapes look so nice. I'm really looking forward to diving in deeper.
I added a simple ci::Timer to get the number of milliseconds spent per frame in the RenderToTexture sample, and found that the NanoVG performance is generally better than the Texture Proxy performance (on a Mac Pro w/ AMD Firepro card). When running in Release with 512 shapes, I see the following frame times:
My guess is that the proxies aren't really worth it unless the underlying shape is very complex.