Complete
over 4 years ago

WERETECH-11147

Fixed

The burn-in protection on Venu2(s) devices with CIQ4 falsely triggers and turns off the display

I have ported several watch faces with Venu1 AOD support to the Venu2 and Venu2s devices.

My AOD modes are straight forward. I'm using a dense pattern clearing every 2nd pixel row or column on the screen alternating each minute starting with the first row/column or the second row/column.

This ensures that less than 10% of the pixels are on and no particular pixel is on for more than 1 minute.

On the Venu2 the simulator detects a screen burn-in. On the Screen Burn-In Simulation window it looks like the overlay pattern is ignored.

Also some drawing artifacts are missing on the burn-in screen for example the minute and hour hands.

I'm in contact with 2 other developers who have similar problems with at least some of their watch faces.

I already uploaded my watch faces with Venu2 support to the Connect IQ store and received feedback from a user who also owns a Venu1 that

the AOD is not working on his new Venu2. - It turns off the screen.

So this is potentially not only a problem of the simulator but also of the actual device.

Here is a screen recording of the problem in action highlighting the differences between Venu1 and Venu2:

https://drive.google.com/file/d/123bDerdGzCovWEcJlxonKbRBSo96lqrq/view?usp=drivesdk

Manuel B.
  • over 4 years ago in reply to jim_m_58

    Jim,

    With the greatest respect, please allow that at least some of the developers here are capable of independent thought.

    I have already posted (several times and in several places) that I am able to trigger this bug when I have nothing more than a dc.clear() after setting colour to black.

    THIS IS A BUG. IT IS A BUG WHICH HAS BEEN VERIFIED BY VERY MANY DEVELOPERS DEVICES AFTER VERIFYING THAT THEIR CODE IS VALID ON CIQ3.2 AMOLED DEVICES.

  • over 4 years ago in reply to Former Member

    What it looks like to be is you are turning on more than 10% of the pixels, then using the lines to turn some off.  Try reducing what you display and just use the lines to insure that a single pixel isn't on too long.  The larger (416x416) display could be why you don't see it on the other venu devices.

    Maybe do something like draw the top 1/3 of the data. draw the lines over that, than the middle 3rd, draw the lines over that, then the bottom 3rd.

    BTW, low power on the venu2 and venu2s is working fine for me in the sim. But I never have more than 10% of the pixels on.

  • Former Member
    Former Member over 4 years ago

    Hi all,

    We are running into the same issue over here with our faces. We use the same strategy as other devs in here, drawing lines across the screen (that reduce the amount of pixels to below 10%), which alternate each minute.

    This strategy has worked fine on venu, venud, venusq and d2air. 

    It completely fails on venu2 and venu2s, as others have noted here, the simulator (and apparently the real devices) act as though the pixel count is higher than it should be when it's actually not.

    I use this little tool to figure out what percentage of pixels are active: https://codepen.io/NiVZ/pen/dyyPomB 

    Demo of watchface having only 7% of pixels turned on

    You can see above that we're only using 7% of pixels.

    Even if I double the thickness of my lines, the AOD simulator still reports too many pixels drawn and turns the display off.

    Demo of watchface being shut off due to Garmin thinking that pixels are still active

    You can see here that Garmin thinks that all pixels are turned on when in reality there are black lines being drawn overtop of the screen's contents.

    As others noted above, it's almost as if Garmin is counting active pixels too quickly.

    Can this be fixed in any way without having to load in another font or draw using a BitmapBuffer?

    Is Garmin ever going to fix this issue? 

  • over 4 years ago

    Hi,

    A small but interesting finding that gives a workaround:

    Following the discussion in the forums, I swapped from dc.draw to draw my overlay to using a font to draw my overlay.

    Seemingly, drawtext is quicker or something and Venu 2 appears to work with my overlay as text.

    And... as another interesting finding (that might well be a bug report in its own right) it seems that some devices (definitely VenuSq) take into account parts of the screen drawn at y = -1 so I have had to fudge my dc.drawText command to start at y = -3 for safety.

    G

  • over 4 years ago

    "Not sure which vacuum all the replies are being sucked away to, "

    Unfortunately, you have to click on Newest (or Oldest) to see more than 5 replies in the Bug Reports section.

    Just another joy of using Garmin/Garmin-adjacent software. (Garmin didn't write this forum platform, but they chose it...)

    Garmin is aware of the issue but it looks like it won't be fixed (by them).

    forums.garmin.com/.../meta-connect-iq-bug-reports-section-doesn-t-show-more-than-5-comments-unless-you-click-oldest-or-newest