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 1518 - SDL_UpperBlitScaled ignores alpha
Summary: SDL_UpperBlitScaled ignores alpha
Status: WAITING
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.0
Hardware: x86_64 Linux
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-14 16:33 UTC by ahelper2
Modified: 2017-11-07 12:40 UTC (History)
3 users (show)

See Also:

Attachments
test case (6.38 KB, text/x-csrc)
2017-11-07 11:12 UTC, Sylvain 		Details
image (638 bytes, image/png)
2017-11-07 11:12 UTC, Sylvain 		Details
updated testcase (6.48 KB, text/x-csrc)
2017-11-07 12:40 UTC, Sylvain 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description ahelper2 2012-06-14 16:33:21 UTC 
SDL_UpperBlitScaled is able to scale a surface and blit it, but it ignores the alpha value of the source surface.  Instead of alpha blending, it blits the source surface with a white background.

Given:

SDL_Surface *target; // target surface, RGBA
SDL_Surface *src; // Contains RGBA surface
float scale = 0.5; // Scaling factor
SDL_Rect clip = {0,0,(int)(src->w * scale), (int)(src->h * scale)};

This blits it properly with alpha blending:

SDL_Surface *copy = SDL_ConvertSurface(src, target->format, 0); // Ensure that format matches
SDL_UpperBlit(copy, nullptr, target, &clip);
SDL_FreeSurface(copy);

This scales it, but alpha is ignored, giving a white background to blitted surfaces:

SDL_Surface *copy = SDL_ConvertSurface(src, target->format, 0); // Ensure that format matches
SDL_UpperBlitScaled(copy, nullptr, target, &clip);
SDL_FreeSurface(copy);

Additional Info:
  SDL revision: 6328:9a65b2bd4e01
Comment 1 scott.e.graves 2013-02-21 14:11:22 UTC 
This bug doesn't seem to be isolated to Linux x86_64. I'm experiencing the same issue on WinXP/32, Win7/32 and Win7/64. For now, I've substituted SDL_SoftStretch() but there is a significant performance hit using this method. 

I've been unsuccessful to date resolving the issue in source but the issue still exists in the latest source snap 2.0.0-6894 as well as trunk. Glad to help out with examples.
Comment 2 Sam Lantinga 2013-03-01 01:08:29 UTC 
Yes, a simple example would be great.  Thanks!
Comment 3 Philipp Wiesemann 2015-05-06 19:39:00 UTC 
Maybe this is or was related to bug 2976.
Comment 4 Sylvain 2017-11-07 11:12:18 UTC 
Created attachment 3073 [details]
test case
Comment 5 Sylvain 2017-11-07 11:12:39 UTC 
Created attachment 3074 [details]
image
Comment 6 Sylvain 2017-11-07 11:20:56 UTC 
Here's a testcase and it's image, tested on latest and also SDL 2.0.0. On ubuntu converting to ARGB8888 and RGBA8888.

It seems to me it SDL_UpperBlit and SDL_UpperBlitScaled behave correctly.
But with SDL_SoftStretch, Alpha is copied instead of being blended.

But two things seems wrong :
- SDL_SoftStretch, Alpha is copied instead of being blended.

- Depending on the position of SDL_UpperBlit : 

     SDL_UpperBlit(surf, NULL, surf_target1, &clip); // Normal Blit
     SDL_SoftStretch(surf, NULL, surf_target3, &clip); // Aie, no scaled !
     SDL_UpperBlitScaled(surf, NULL, surf_target2, &clip); // Aie, no scaled !

or 

     SDL_SoftStretch(surf, NULL, surf_target3, &clip);
     SDL_UpperBlitScaled(surf, NULL, surf_target2, &clip);
     SDL_UpperBlit(surf, NULL, surf_target1, &clip);  // Normal Blit

The following blit are scaled or not ! 
I'd say some "InvalidMap is missing somewhere ...
Comment 7 Sylvain 2017-11-07 11:25:32 UTC 
SDL_SoftStrech() behave as if SDL_BLENDMODE_NONE was enabled on source surface, instread of SDL_BLENDMOD_BLEND
Comment 8 Sylvain 2017-11-07 12:40:11 UTC 
Created attachment 3075 [details]
updated testcase

I got mistaken because UpperBlit modified the destination rect parameter. hence the strange behavior.

About, SDL_SoftStrech(), I think this is the default behavior looking at the code as it does a plain copy, no blending.