Complete
over 2 years ago

BUG: some newer devices clear the screen on every view update. Simulator behaves differently

Some users have reported issues with my app Maze (https://apps.garmin.com/en-US/apps/3a4436a8-1126-4539-a2f2-aefb319a0ef0) and Snake (https://apps.garmin.com/en-US/apps/e443b0cc-8046-4d76-830f-e87517cf14b6), where the screen will go black after starting to play the game.

For efficiency, the screen is drawn using Dc calls, the view's onUpdate does not call the parent, and only the changed parts of the screen are redrawn: during gameplay on Maze, the previous location of the ball is blanked out, and the new location is drawn.  The event loop is run by a timer that calls Ui.requestUpdate() every 100ms.  This method has worked since I originally developed the games for my Forerunner 235.  

However, with newer devices - specifically, the Venu and the Forerunner 55 - this does not work.  For some reason, the display gets blacked out on every call to View.onUpdate. This only happens on the physical watches, not in the simulator, so I have no way to test this behaviour!I can create the undesired behaviour in the simulator by adding a call to View.onUpdate(dc) at the top of the onUpdate method in my view class.

So, here are my requests:

* please correct the behaviour on these watches

* if this behaviour was a desired change, please update your documentation to make it clear that we can no longer perform incremental updates to the screen

* please fix the simulator so that it behaves the same as these watches

* in the meantime, please tell me if there is a workaround for this issue.  I believe my code is correct since it has behaved correctly for years, and there is no detail in the documentation that says that what I'm doing is no longer possible

More details available on request - for some reason I can't add an image here.

ak6i
  • over 2 years ago

    Yes, many things is unfortunately bad organised but "not my business not  my rules".

    But, yes no info about fixing bugs is very bad

    1. I report bug

    2. off course have to make workaround

    3. Garmn fixes (or not),  nobody know about it. Maybe there are hundreds bugs and hundreds not fixed - and it's  a problem...

    4. I have in code still workaround because don't  know if fixed and don't want expose users for crash (not my fault).

    So, why I report bugs if don't benefit form fixing?

  • over 2 years ago in reply to _psx_

    Exactly. For me it’s also a bug that the simulator doesn’t behave the same as the watches.

     It’s also a flaw in the bug reporting process that an issue like this can be marked as complete without any explanation from the Garmin side and without the acceptance of the reporter. This whole experience has left a bitter taste in my mouth; I’m now a lot less inclined to bother writing apps for the Garmin ecosystem.

  • over 2 years ago

    Garmin thinks that is normal that the same kind devices (mips) can run in different way in onUpdate - for me it's a bug because it's the same platform and API is exactly for cover any differences.

    But  in amoled devices is a case of device - pixel light if there is voltage, no voltage black pixel so clearing screen is simple take the voltage off from display and it is simple, you don't to have to analise each pixel...

  • over 2 years ago

    I have no idea why this was marked complete. It’s not!

  • over 2 years ago

    Oh no, we didn't understand each other :) We both are right, simple it impossible to draw  antialiased  on buffered bitmap when palette is selected (the same is on f6).

    And maybe you are right, maybe for app/widgets there is no clearing screen for other than amoled devices (I have also widget/app but simple draw every second without checking anuthing).