Faster drawing of opaque primitives by disabling blending

[hobby]

I have an application that draws many shapes, where most of them are opaque. Separate batches are maintained for opaque and non-opaque drawing operations, and they are rendered by calling RenderTarget::draw() with VertexArray.

In order to accelerate the drawing without modifying SFML, what I've been doing so far is manually disabled blending before opaque draw() calls. This has resulted in significant performance boost, but as a solution it feels a bit dirty. The cleaner alternative of using BlendNone was not as effective, resulting only in modest improvement way behind what disabling blending achieves.

I propose that as a performance optimization, SFML will disable blending when BlendNone is selected.

[eXpl0it3r]

Do you actually encounter performance issues or are you just optimizing for optimization's sake?

[hobby]

That's a good question to ask regularly.

I started with naive use of SFML and was quite happy with that for a long time. But then, once run on a computer without GPU, the application demonstrated big lags, e.g. shapes not following the mouse during drag & drop.

I should note that I also target SW renderers (think business environment) and can't assume that the application will run full screen and be able to hog all resources. It may be that environments like this are not in SFML's target audience. But note that the disabling of blending is also done by Qt renderer on more modern platforms:

Another benefit of using opaque primitives, is that opaque primitives do not require GL_BLEND to be enabled which can be quite costly, especially on mobile and embedded GPUs.

I believe this optimization is quite easy to implement in SFML regardless of whether the state cache is removed or not, and can provide ``easy money'' in terms of performance (e.g. in use cases such as tile map).

[Nexus]

Do you suggest to do this optimization for all sf::Drawable objects rendered with sf::BlendNone? Or rather "behind the scene" for other blend modes, when non-textured sf::Shape objects are rendered, filled and outlined with a color that is either fully opaque (alpha=255) or fully transparent (alpha=0; in that case they needn't be drawn)?

Are you sure that disabling the blend mode is still faster than e.g. constant switching of that state?

If you target software renderers, SFML is not the library of choice...

[hobby]

Do you suggest to do this optimization for all sf::Drawable objects rendered with sf::BlendNone? Or rather "behind the scene" for other blend modes, when non-textured sf::Shape objects are rendered, filled and outlined with a color that is either fully opaque (alpha=255) or fully transparent (alpha=0; in that case they needn't be drawn)?

I wouldn't go that far as to work behind the scene, as this may actually degrade performance unless a full batch renderer is implemented inside SFML. My suggestion is minimalistic - disable blending only when the user explicitly specifies BlendNone. This minimizes the risk of implementing it (see below).

Are you sure that disabling the blend mode is still faster than e.g. constant switching of that state?

In the general case? No. That's why I think it's important to see what other frameworks do.
Note that the worst case of constant switching will occur only if the user explicitly switches blend modes, which is discouraged anyway for performance. Not to mention that many users may be able to develop with SFML without changing its default blend mode, so this only applies to users who actively modified it.

If you target software renderers, SFML is not the library of choice...

Why is that?
I can see why SFML is suboptimal for applications, with its constant need for redrawing the entire window even if nothing has changed, not hinting at which rectangular areas of the window have been invalidated.
But suppose that you were to develop a game, with animations and all that, why would SFML be inferior to other libraries with respect to running on software renderers?