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.
Parents
  • 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? 

Comment
  • 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? 

Children
  • over 4 years ago in reply to Former Member

    I think I was right

    there was black, you can see it while zoom it

  • over 4 years ago in reply to jim_m_58

    Just to complete the picture a little...

    //////////////////////////////

                // Set to black
                dc.setColor(Graphics.COLOR_BLACK,Graphics.COLOR_BLACK);
                
                // THIS CAUSES CRASH WITH VENU 2 IN LOW POWER
                // dc.fillRectangle(-3, -3, dc.getWidth()+6, dc.getHeight()+6);

                // AND THIS CAUSES CRASH WITH VENU 2 IN LOW POWER
                // dc.clear();
                
                // BUT THIS IS FINE WITH ALL VENU... stripeFont is a 64x64 tile of stripes and stripeStr is enough characters to fill the screen
                // The -3 magic number is due to what I think is a bug with VenuSq that sometimes includes pixels that are not on the screen rectangle 
                var h = dc.getHeight();
                var pos = -3; // Seems to be a pixel or two prior to the screen...
                do {
                    dc.drawText(-3, pos, stripeFont, stripeStr, Graphics.TEXT_JUSTIFY_LEFT);
                    pos += 64;
                } while(pos<h);
    //////////////////////////////////////
  • over 4 years ago in reply to Former Member

    I have a number of WF's that use custom fonts that work fine in low power mode for the venu2 in the sim.  I generally don't draw much - like just the time and maybe a couple other things (temperature, HR, etc).

    The graphic pool in 4.0 may also be involved.  

  • Former Member
    Former Member over 4 years ago in reply to jim_m_58

    That's what I thought too, originally.

    What's actually happening is that anything drawn using custom fonts to the dc seem to be counted as "active" pixels even if there is other crap drawn on top of them (ie. black lines, etc). 

    If you have a watchface with no custom fonts (so you're just using system fonts and/or graphics), those can have black lines drawn on top and the pixels which were drawn on top of will be ignored and NOT counted as "active" pixels (which is expected behaviour).

    I'm going to record a demo video with two sample projects in a couple of hours that will make it clearer what's going on here. 

    But long story short: any custom fonts (and maybe bitmaps?) drawn to the dc will not work in AOD on venu2 and venu2s.

  • over 4 years ago in reply to 9635560

    If I don't move the data displayed (top half of screen then bottom half of screen), I overlay with a checkerboard (a custom font) and shift that every minute.  Sounds like it's possibly the draw lines.

    Sounds like a clue!