Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Polygon2D is extremely slow compared to Sprite rendering #19943
OS/device including version:
I've had the same results in a game project where I've attempted to create levels from Polygon2D objects. Usually optimized meshes would be very useful for optimizing fillrate, but this performance seems to make it impossible to utilize. I feel like this is going to hurt many graphically demanding 2D-projects.
Steps to reproduce:
Minimal reproduction project:
Every time update() is called or every frame?
I'm working on a PR that reduces the number of glBufferSubData calls by splitting canvas_render_items implementation into the following parts:
Currently there is a per-polygon glBufferSubData call made and that hurts performance.
Some preliminary tests for the new approach seem to be promising (with ~4x FPS increase -> 240 vs 60 FPS).
I am having a big problem with this now.
What I need to do is to be able to submit triangles as vertices with uvs using
However doing so with less than 100 calls on iOS results in less than 20 fps. (It goes down to less than 10 fps when I do it in my game, compared to 60fps with out those calls.)
It is disappointing to see that Godot 3 does not do any automatic batching.
I would actually want to try and fix this .. or maybe at least write a new add_triangle_array call that would batch them, or maybe use something else that doesn't get impacted by the multiple
However, I would like to ask first ... why is iOS using only GLES3?
I would like to implement this in only GLES2 which I thought was the recommended mobile renderer, however iOS is hardcoded to use GLES3?
Just looking at #20077 speedup results:
That is the difference between 2D polygons being actually useful or not.
EDIT And looking at the code, it was a very well architected solution which would have been a great framework to later add batching. This and the other batching pull request, if combined into one would be perfect. (Then could optimize to reduce the number of flush calls to allow batching across canvas items.)
I don't know why there is such an all or nothing mindset though. reduz wants full batching so doesn't allow this PR even though it would be a good stepping stone. Then the batching PR gets completely reverted because of 9 patch rendering on Android instead of maybe just going back to old rendering for 9 patches?