On 06/24/2016 08:45 AM, Roland Scheidegger wrote:
For what formats is this really needed? I think that usually if you have
a rgb surface, the corresponding rgbx format should be used instead of
rgba (which implicitly has the alpha == 1 property for blending). But
maybe some formats are missing...
On 24.06.2016 16:40, Brian Paul wrote:
On 06/24/2016 03:56 AM, Nicolai Hähnle wrote:
On 24.06.2016 04:07, Brian Paul wrote:
If the user requests an RGB drawing surface but we actually create an
RGBA surface, we need it to act as if A=1. For blending, this means
adjusting the blending terms to
For what formats is this really needed? I think that usually if you have
a rgb surface, the corresponding rgbx format should be used instead of
rgba (which implicitly has the alpha == 1 property for blending). But
maybe some formats are missing...
Roland
Am 24.06.2016 um 04:07 schrieb Brian Paul
On 06/24/2016 03:56 AM, Nicolai Hähnle wrote:
On 24.06.2016 04:07, Brian Paul wrote:
If the user requests an RGB drawing surface but we actually create an
RGBA surface, we need it to act as if A=1. For blending, this means
adjusting the blending terms to use 1/0 instead of
DST_ALPHA/INV_DST_ALP
On 24.06.2016 04:07, Brian Paul wrote:
If the user requests an RGB drawing surface but we actually create an
RGBA surface, we need it to act as if A=1. For blending, this means
adjusting the blending terms to use 1/0 instead of DST_ALPHA/INV_DST_ALPHA.
Drivers can use this flag to determine when
If the user requests an RGB drawing surface but we actually create an
RGBA surface, we need it to act as if A=1. For blending, this means
adjusting the blending terms to use 1/0 instead of DST_ALPHA/INV_DST_ALPHA.
Drivers can use this flag to determine when that's needed.
A previous patch I poste