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 1424 - Handling of alpha channel in Altivec accelerated blit functions
Summary: Handling of alpha channel in Altivec accelerated blit functions
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: 1.2.15
Hardware: PowerPC Mac OS X 10.5 (PPC)
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-19 09:38 UTC by evilbite
Modified: 2012-02-20 17:57 UTC (History)
0 users

See Also:


Attachments
SDL_blit_N.patch (1.43 KB, application/octet-stream)
2012-02-19 09:38 UTC, evilbite
Details

Note You need to log in before you can comment on or make changes to this bug.
Description evilbite 2012-02-19 09:38:21 UTC
Created attachment 823 [details]
SDL_blit_N.patch

There is only one Altivec accelerated blit function (ConvertAltivec32to32_prefetch() or ConvertAltivec32to32_noprefetch(), depending on the CPU used) that is supposed to handle all alpha combinations. This works as follows for every pixel line:
1. Blit single pixels until an aligned address is reached
2. Accelerated blit as far as possible
3. Blit single remaining pixels
Part 2. is set up correctly to handle different combinations of the alpha channels of the participating surfaces. Parts 1. and 3. only do a simple copy of all the pixel's components from souce to destination. But when the source surface has no alpha channel (Amask is 0, e.g. the video surface) the surface's alpha value must be used instead. Otherwise crap (uninitialized data) is being copied to the destiniation's alpha channel.

The attached patch is a quick'n'dirty solution to the problem. A more sophisticated solution might require separate functions for different combinations of the alpha channels of the participating surfaces.

The problem seems not to come up when the width of the destination surface enforces all pixel lines to start at an aligned address. This can easily be accomplished by using a suitable pitch value for all surfaces, but SDL_CreateRGBSurface doesn't make use of this right now.
Comment 1 Sam Lantinga 2012-02-20 17:57:25 UTC
Fixed, thanks!
http://hg.libsdl.org/SDL/rev/7a2e0f7b30cb