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

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

Children
  • 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!

  • over 4 years ago in reply to jim_m_58

    I'm on a pc, too.

    It really does look like the CIQ4 devices simply object to either the time taken or something else using dc.draw() methods.

    I'm happy in that the font method of doing AOD is actually a gazilliion times easier than what I had been using, but it is a fact that I have precisely zero dc.draw() burnin protections that work.