Complete
over 2 years ago

WERETECH-12048

Fix will be applied to next SDK release.

Devices affected will have firmware updates in a future firmware build.

No more transparency for font background on bufferd bitmap since SDK 4.0

Hi, 

I use a bufferedBitmap with color palette and custom bitmap fonts without antialiasing.

Since SDK 4.0 the font background  is not more transparent. The color is defined before:

dc.setColor(CustomColor, gfx.COLOR_TRANSPARENT);
   

The code is running many years without problem.

I don't understand, what's going wrong with new SDK

FSeifert
Parents
  • over 2 years ago

    In SDK 4.x simulator, if you use a buffered bitmap with a palette following the Analog SDK sample, drawing text with transparent background into the buffer produces text with random foreground color and background that is definitely not transparent.

    It looks like for drawing text into the offscreen buffer the graphics engine gets confused when transparent color is not present in the palette.

    Adding transparent color (-1) to the palette fixes the randomness, but it shows another problem:

    After drawing text into the buffer, the resulting bitmap appears to retain the 'transparent attribute' for the pixels of the transparent text background. So when this buffer is copied to the screen, these 'transparent' pixels preserve the previous content of the screen.

    This doesn't make sense and it is not happening with other draw operations, e.g. line, circle or rectangle.

    It looks like for text drawing we have confusion between 'SOURCE transparency' (target pixel color should be kept) and 'TARGET transparency' (target pixel color should be void).

    Sadly the latter is now making its way into the real firmware in the field, as seen on 945 LTE.

    Can we please have it back the way it was in SDK 3.x? Use 'SOURCE transparency' when drawing transparent pixels and do not require the transparent color to be defined in the palette? It is not needed there unless 'TARGET transparency' is employed, but then it should be consistent for all drawing operations not just text, and there should be another way to achieve 'SOURCE transparency'.

Comment
  • over 2 years ago

    In SDK 4.x simulator, if you use a buffered bitmap with a palette following the Analog SDK sample, drawing text with transparent background into the buffer produces text with random foreground color and background that is definitely not transparent.

    It looks like for drawing text into the offscreen buffer the graphics engine gets confused when transparent color is not present in the palette.

    Adding transparent color (-1) to the palette fixes the randomness, but it shows another problem:

    After drawing text into the buffer, the resulting bitmap appears to retain the 'transparent attribute' for the pixels of the transparent text background. So when this buffer is copied to the screen, these 'transparent' pixels preserve the previous content of the screen.

    This doesn't make sense and it is not happening with other draw operations, e.g. line, circle or rectangle.

    It looks like for text drawing we have confusion between 'SOURCE transparency' (target pixel color should be kept) and 'TARGET transparency' (target pixel color should be void).

    Sadly the latter is now making its way into the real firmware in the field, as seen on 945 LTE.

    Can we please have it back the way it was in SDK 3.x? Use 'SOURCE transparency' when drawing transparent pixels and do not require the transparent color to be defined in the palette? It is not needed there unless 'TARGET transparency' is employed, but then it should be consistent for all drawing operations not just text, and there should be another way to achieve 'SOURCE transparency'.

Children