We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4258

Summary: Problem with transparency management
Product: SDL Reporter: Alain <alain.Bonnefoy>
Component: renderAssignee: Sam Lantinga <slouken>
Status: RESOLVED ABANDONED QA Contact: Sam Lantinga <slouken>
Severity: critical    
Priority: P2 CC: alain.Bonnefoy
Version: 2.0.8   
Hardware: All   
OS: Linux   
Attachments: My stuff to verify the problem

Description Alain 2018-09-12 09:14:27 UTC
Created attachment 3304 [details]
My stuff to verify the problem

Hello,
This problem concerns at least SDL_RENDERER_ACCELERATED. I didn't made tests with Software Renderers.

The test is done on various Linux platforms but it certainly concerns SDL2 in general and since the begining. It's not a new problem as I found games development forums already talking about it in 2015 (Westnoth)!

After having read many forums relating this problem about SDL2 and SDL2_gpu uses in game development, maybe I still didn't fully understand how to use blend modes and maybe when to call these functions exactly but I also think there is a real problem in SDL2 about transparency management.

The problem is that one:

I'm trying to RenderCopy an alpha image in a transparent or semi-transparent texture and then RenderCopy this result in a background.
The report is that original pixels are lost during RenderCopy on even fully transparent texture and the more transparent intermediate texture you add, the more pixel you loose whereas, as we are talking about transparent texture, no alteration should be perceived on the result.

Here is a reference image which illustrates what I'm expecting for:
![reference](https://i.imgur.com/dCsknVp.png)

So I wrote a test (main.c attached in a zip) which is supposed the produce the same result and [here](https://i.imgur.com/l8HRg68.png) is what I get. 

I explain:

In the 1st square on the left, I render the white disk directly on the background. The result is already a bit more transparent than expected.

In the 2nd square, the white disk is rendered on a solid black texture and then the result is rendered in the background. The result is as expected.

In the 3rd square, the white disk is rendered in a half transparent texture and the result is rendered in the background. You can see that the white disk is more transparent than in the 1st square which is not normal.

In the 4th square, the white disk is rendered in a fully transparent texture and the result is rendered in the background. You can see that the white disk is more transparent than in the 1st square which is not normal. the transparent intermediate texture shouldn't alter the white disk in any way.

In the 5th disk, I render the white disk in a fully transparent texture. Then I render this result in another fully transparent texture, then this result in the background. The white disk is again more transparent than in the 4th square, showing that transparency filters out pixels in some way!
 
This behavior is a very very big problem and I really hope you could quickly take care about it.

I attached my test source code and the images used to experiment.

Kind Regards,
Comment 1 Alain 2018-09-12 09:27:36 UTC
I also tried to play with SDL_ComposeCustomBlendMode() and it's not better and even worst as it's not possible to set the target texture transparency value anymore. It's opaque or transparent.
Anyway, the rendering of the white disk is not better with any of the 32000 or more commbinations.
Comment 2 Alain 2018-12-10 14:13:11 UTC
tested with openGLES2 accelerated
Comment 3 Alain 2019-01-18 10:18:24 UTC
After looking deeply in the SDL, my apologies, alpha blending is well computed.
It's just that alpha blending is not the right way to process multi layers mapping.


For this, according to our experiments, the following formula would give good results in multi layers, 

dRGB=sRGB*(1-sA)+dRGB*sA*dA

Unfortunately, the second term cannot be computed with custom blend modes. :-(

I would be very interested to know how gimp process the layers. Didn't take time to look at this...
 
Then the last rendering (on the screen) would be done in classic alpha blendig.