The biggest point of confusion and friction in the draw API are how many of the draw_ functions set state upon drawable objects, i.e. the sprites/shapes. The state gets persisted on the object itself until the next render_to gets called. However, the render settings only get apply when render_to is called. This creates two very different lifetime schemes, and forces users to think about splitting up their draw calls and manually issuing render_to.
It's probably best to shift to a more "declarative" style where any render state changes opaquely separate draw calls under the hood. This way users can freely set anything, including uniforms, and a dirty flag system can be used to split up and submit draw calls as appropriate. This would make draw call counts more opaque and a little more difficult to diagnose when they get high, but, it's not a big deal. The gains on simplifying the API are quite good.
RandyGaul
commented
2 months ago
The biggest point of confusion and friction in the draw API are how many of the draw_ functions set state upon drawable objects, i.e. the sprites/shapes. The state gets persisted on the object itself until the next render_to gets called. However, the render settings only get apply when render_to is called. This creates two very different lifetime schemes, and forces users to think about splitting up their draw calls and manually issuing render_to.
It's probably best to shift to a more "declarative" style where any render state changes opaquely separate draw calls under the hood. This way users can freely set anything, including uniforms, and a dirty flag system can be used to split up and submit draw calls as appropriate. This would make draw call counts more opaque and a little more difficult to diagnose when they get high, but, it's not a big deal. The gains on simplifying the API are quite good.