Re: [Tuxpaint-devel] Display bugs in SDL 1.2 (master branch) Tux Paint under X-Window?

[Karl O. H. <ka...@hu...>]

Pere Pujal i Carabantes skreiv 07.07.2022 00:06:
> Are those brushes?
>
> rgrep rotate data/brushes/
> data/brushes/arrow.dat:rotate
> data/brushes/rotating_dash.dat:rotate

Yes.


> I remember having to use plain SDL_BlitSurface in the sdl2.0 branch when
> rotational brushes were added,
> was the 6891266eeebd0aa1268dd6ef4c699e3d80e10958 commit
> It was for other reasons, no SDL(2)_gfxBlitRGBA() available for the SDL2 lib,
> but as you say the sdl2.0 performs right here, the only difference between
> master and sdl2.0 in this area coming to my mind is this one
>
> maybe you could try if it is worth too to use SDL_BlitSurface() insteadSDL_gfxBlitRGBA()
> in the master branch.

I tried cherry-picking the commit, but it didn’t have an effect. But 
that’s not so strange, as it turns out that this code path is not used 
for these two brushes, only for multi-frame brushes. In other words, 
it’s used for the (working!) arrow_triangles.png brush.

I have also tried changing the colour space (RGB vs. greyscale vs. 
indexed) in the PNG images, as different PNG images have different 
colour spaces, but that didn’t have an effect.

I have narrowed the problem down to this line:

     rotated_brush = rotozoomSurface(img_cur_brush, rotation, 1.0, 
SMOOTHING_ON);

If I instead write

     rotated_brush = img_cur_brush;

then the two brushes are drawn even if I use the black colour – and then 
Tux Paint immediately crashes … So there’s something in 
rotozoomSurface() which doesn’t work properly when the brush colour is 
black?


-- 
Karl Ove Hufthammer