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

  • , thanks for clarifying the use case, I do agree that there is an issue with drawText with transparent bg color on palettized BufferedBitmap.

    The issue is stemmed from the graphic engine change that came with the GPU support, since our simulator is using the latest graphic engine, we are exposed to this issue, but older devices such as fenix 6, FRx45 are not (due to the lack of new graphic engine).

    We will have this fixed in our graphic engine, but the deployment of the fix may not happen till 2022 q2 unfortunately.

    In the meanwhile, please don't use palette for BufferedBitmap for 4.0 (and 945lte) devices, as most of those products have GPU enabled (e.g. venu2, f7, fr945lte etc), palette BufferedBitmap will actually cause the graphic engine to switch to the slower software render rather than taking advantage of the GPU which doesn't support palette (or user transform).

  • Well said, thank you - it seems that this API now in SDK 4 allows no way to draw text without filling its rectangle.

    I think maybe a font could be hacked so that it has reportedly zero line height (unless you want a multiline text), which could force ConnectIQ to draw a zero height background, but it's an ugly hack.

  • Hello Travis, I am setting :alphaBlending to ALPHA_BLENDING_FULL on my 4-bit bitmap, and the described behavior (drawing text on transparent background 'eats up' whatever was in the bitmap before the draw call).

    Do you have a sample code that would draw a text to the bitmap without deleting what is already there? Can such thing be accomplished in SDK 4 (eg. on Fenix 7)?

  • Analyze my case:
    I am making an analog watch face with hands.
    On older devices there is not much memory and I draw hands, inscriptions, icons in a 4-color BufferedBitmap.
    In addition, the clock face has an inscription with a heart rate - it also needs to be updated in real time - once every few seconds.
    To do this, I will select a BufferedBitmap the size of the inscription and draw hands in it too.
    When I need to update the inscription with the heart rate, I display the second, small, auxiliary BufferedBitmap with hands on the first, main, large BufferedBitmap - I restore the original background. Then, in the first, basically, large BufferedBitmap, I print an inscription with a heart rate with a transparent background. In older devices, this works as it should. However, on newer devices with CIQ4, solid rectangles are printed instead of the expected text.

    These watch faces have been on the Garmin Connect IQ App Store for a few years now and didn't cause any problems until the CIQ4 came out.

    I found a way out: devices with CIQ4 have more memory, so I started using BufferedBitmap without a palette for them. But this still has a negative side: 4-color BufferedBitmaps are much faster displayed on the screen, thereby saving energy.

    What is the difficulty in bringing the behavior of the system back to the habitual one?

  • Hi Johnny,

    Thank you for your reply. If as you say "the issue or BufferedBitmap retain the transparent attribute after drawText with transparent bg color, it's mostly by design", then why is the design inconsistent, so that the transparent attribute is retained when drawing text but it is not when drawing other things. What is the intended practical usage scenario that could benefit from this? In your example code you could achieve the same result much easier, just by drawing the text with a yellow background instead. On the other hand, there is at least one usage scenario that seems no longer possible: Drawing text over some kind of a background image, into a buffer with a custom palette, and then copying parts of this buffer during the onPartialUpdate(). This results in the second hand leaving traces on the 'transparent text background'. The only solution I can think of would be to try to redraw the affected parts of the screen each second, but that may be too costly and likely to trigger the power budget exception. Or did I miss something obvious how this could be dealt with?

    Please advise.