#259 brush transparency issue

[revon corvidae]

brushes with transparency appear to not be mapped correctly, causing some of the transparency to remain black instead of turning to the chosen color of the brush.

[William Kendrick]

Thanks for reporting this.

I was able to reproduce this under the SDL2 branch of the repo on my Ubuntu laptop, though not under the SDL1.2 branch (current "master").

I've taken a stab at this by requiring the canvas surfaces ("canvas" and "save_canvas", both of type SDL_Surface*) to be 24-bit. Previously, we were requesting they have the same color depth and RBG bitmasks as the display surface ("screen").

https://sourceforge.net/p/tuxpaint/tuxpaint/ci/53c1c5e99595875d8fac07638202a6d8bf69750e/

[William Kendrick]

Closing, with the hope that my attempt at fixing this doesn't cause further issues! :-D

[William Kendrick]

Spotted some art with strange artifacts on Twitter recently, and had totally forgotten about this ticket. I've asked them to see whether 0.9.29 beta still exhibits this problem. I'm guessing it's very likely fixed, but if not I shall reopen this ticket.

[William Kendrick]

I am seeing this behavior with brushes that use the "rotate" feature. In the attached screenshot, I had adjusted Tux Paint's call to rotozoomSurface() to also scale up a lot. The behavior also occurs even if the rotation angle is set to 0.

Unlike a brush that does not get passed to rotozoomSurface(), and simply SDL_BlitSurface()-ed directly onto the canvas, the alpha parts end up appearing blackened.

The new "Watercolor splotches" brush shows this behavior as well. Compare what you see with the brush using black, vs using any other color.