Hi! I'm following up on a message previous posted by Tillsan (and Dok answered it), but I don't think it was covered properly. I've found the same thing Tillsan has. Scenario: Source image data RGBA with alpha channel Destination image data RGBA with alpha channel Blend soruce onto Destination Result = rgb pixels blended (seemingly) properly. but destination alpha pixel gets modified incorrectly.
What is incorrect? let's take an example. destination has an alpha channel but has been willed with a solid white rectangle (RGBA: 0xff,0xff,0xff,0xff) source has an icon - lets say like the gnome png icons so it has a soft drop shadow where the transparency gradually changes from opaque to transparent at the edges of the icon to show a shadow. when we blend this icon onto the destination, parts of the destination image approximately where the alpha pixel values of the icon is about 0x80 the alpha channel of the destination starts becomming less than 0xff (ie i am guessing about 0xc0 by visual inspection). well - as we can imagine, this is NOT the desired effect. when you blend something on top a completely solid image, you don't want it starting to become transparent! :) now i've done some footwork in the code... i've gotten down to the graphics.c in generic code (i disabled mmx for now to test with just C) and am not using any acceleration for this. man that's complex. you build a function pipeline with a virtual "cpu" (or gfx chip) which has its own accumulator for spans etc. ok ok.. after about an hour of hunting around i thought i'd have to askhere for some narrowing. I've found the stretchblit section that generates the function stack and i see u call the blend src alpha and inverse src alpha in sequence... (kind of odd to me to do that? my own blending code does it all in one pass) so anyway.. i think this needs fixing because it isn't what is meant to happen (me thinks). I don't know if hardware acceleration changes this (i'll have to test). I have sample code that can show this (if you look carefully). so i'm wondering if 1. this should be fixed here - or needs design changes, 2. is anyone already fixing it? 3. am i a stark raving lunatic? :) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] [EMAIL PROTECTED] Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615 -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.