OSDev.org

I am trying to alpha blend the window with the background, using this two formulas



My blending code:


before blending:

after blending:

Is there anything wrong with my code, the results looks odd. I was expecting it to look... more pretty

If your color1 is your window color, and color2 is your background color, then you can probably just ignore Alpha2, at least for now. Your background alpha shouldn't affect the colors of any "layers" above it.

As for your window color, all you need is the ratio of window color to background color. The ratio is the window alpha color divided by 255.

Then, you just add the 3 weighted color components.


This should work fine for your case. Once you get that working, then you can add some logic for calculating the result alpha value, so that you can combine two non-background images, but it's a little more complicated, because you are going to have to make some decisions about how your alpha blending is going to work.

But let us know if that solves your immediate problem.

It _looks_ to me that you're picking background pixels from wrong locations. Are you sure you are getting the pixel data correctly? Esp from background window backing buffer.

Thanks SpyerTL and dozniak !
I just fixed it
The formulas were correct, like dozniak said, I actually fetched the pixels at wrong location.
It looks good now

Moving window is significantly slowed down since the color of the moving window needs to be recalculated again at every move.
Any ideas how to deal with this?

I'd probably only drag an outline of the window and then repaint the entire thing once movement has stopped/mouse has been released.

Yep. Alpha blending is noticeably slow, unless you can get some hardware acceleration working for your specific video card.

The CPU just isn't powerful enough to calculate that many pixels without the user noticing.

You may want to look into writing this method in ASM (or in an assembly block), and using SSE extensions, which should make this code run around 4x faster, or more.

Just to make sure: it's not reading from the video memory but something from RAM, right? Because reading from video memory is the absolute worst thing you could ever do. And also make sure it's not just the emulator being slow.

Otherwise yeah, alpha blending is slow. You can try to optimize the blending function (huh, is that integer converted to float with separate multiplication and division (which can't be optimized away unless you use -ffast-math) and then more float divisions and then converted back to integer, on every pixel? x_x). Microoptimizing generally is not useful but in this case it'll be iterating over many thousands of pixels (or millions if the window is large enough) so you definitely want to speed it up as much as you can.

Afaik there are SSE/AVX functions to specifically help with this sort of thing (alpha blending), if you don't want to use asm you could use gcc intrinsics for that.

Hi,



I'm not sure that I really want to mention it (because I prefer "correct" over "fast"); but with 8-bit integer alpha it's much faster to divide by 256 (when correct code would divide by 255). This allows you to do something like "out_blue = (blue1 * alpha) + (blue2 * ~alpha)) >> 8;".

Another (even faster) hack is to only use "50% alpha", so you can do something like "out_blue = (blue1 + blue2) >> 1;".

For 100% correct you need to take gamma into account and use "pow()". In practice this becomes something like "out_blue = gammaTable[ reverseGammaTable[blue1] * alpha + reverseGammaTable[blue2] * (1.0 - alpha) ];".


Cheers,

Brendan

SSE...

http://wm.ite.pl/articles/sse4-alphaover.html

AVX...

https://breeswish.org/blog/2015/07/26/avx2-alphablend/

more speed... MIT licensed.... well written...

https://github.com/skywind3000/BasicBit ... p_SSE2.cpp

worth a look if only for the 128bit memcpy

(writing ～ instead of the actual ASCII symbol because the forum's font makes it look like - instead)


That was pretty much my first post here lol

I think you got the calculation wrong though, because doing it that way means you can never get 255 (don't forget that shifting rounds down). It should be out_blue = ((blue1 * alpha) + (blue2 * ～alpha) + 255) >> 8. That +255 causes the entire range to be skewed so the extreme values always give the correct result after the shift. Also don't forget to make sure that ～ applies as a byte-sized value (hint: C will cast to int then apply ～ which won't be nice, so you better account for that).

And yeah it's not correct but if performance is an issue then better to have it look "somewhat" OK. Probably not worth the effort being correct until you can use the GPU to crunch numbers, making the UI feel more responsive to the user is more important than cosmetic details.

EDIT: right, I just remembered the other possible way to fix the calculation
out_blue = ((blue1 * (alpha + 1)) + (blue2 * ～alpha)) >> 8

That +1 may be more useful since it could end up compiled into an INC (also since you'd be using alpha+1 and ~alpha three times each, they're likely going to be computed once and stored into their own variables then their result reused).

Does SSE works on emulators like QEMU and BOCHS ? I tried them before and didn't see much improvement.

I think you can enable SSE and other extensions with the -cpu flag in QEMU. I'm unsure about Bochs though.