Screen is cleared in onUpdate ON SOME DEVICES, although onLayout is empty and I don't call View.onUpdate()

Hi, on some devices (like a user's fenix 8 - 47mm, Solar and my own Edge 840 (non solar), the screen is cleared at every onUpdate, although the onLayour function is empty and I don't call View.onUpdate in my own onUpdate function. I do that so I can continue drawing a graph where I left off in the previous onUpdate and when the whole graph is done, I set a variable (mNoChange) to true. As long as this variable is set to true, onUpdate simply exit. It works well on my Fenix 7S Pro but on my Edge 840, the screen is ALWAYS cleared when onUpdate is called. The only time I clear the screen myself (dc.clear) is when noChange is false (which happens if I press a button or touch the screen to interact with the graph) so I can redraw the graph and I right next after, I write a text (battery level). That text isn't shown so it's NOT because it runs that dc.clear() function. Touching screen do redraw the graph but it's cleared again on the next onUpdate when mNoChange is true. The odd thing is this happens only on my real device, I can't duplicate in the simulator, even if I use the same data to draw the graph on both my device and in the simulator. Is that a known issue for some devices? If so, is there a way around it? It kinda put a wrench in my code to prevent a crash caused by the graph taking too long to draw.

Thanks.

Edit: Well, just saw some posts from a few years ago that "On some devices the screen gets cleared before onUpdate is called". There goes my idea And here I though I was being clever So back to square one, how to prevent onUpdate from crashing by taking too long while drawing something like this!

There are 2498 data points being plotted, although the data points are averaged to drop the drawing to 434 pixel wide (width of the drawing area) as there is no reason to draw over and over the same pixels. Even doing that, and other optimization, it would crash with a CODE EXECUTED FOR TOO LONG. My solution was to stop after 900 ms, save where we were and request a new view update. On the next update, it would continue where it left of and then leave the screen alone when finished until the user interacted with it, new data happened or the battery level changed. It worked so well on my Fenix 7S Pro

Top Replies

All Replies

0 SylvainGa 4 days ago in reply to FlowState

Yeah, I go by reference. I don't copy one buffer into the other. Like you said, I don't clear the buffer, I create a new one when it's time to redraw the screen and let Monkey C's garbage collector do the clean up.

At first, I wanted to use an array of two buffers and use an index variable to specify which buffer is being drawn and which one is being displayed. I might still try it and compare the time it takes between both to see which one is more efficient.

0 SylvainGa 3 days ago in reply to FlowState

So I checked how long it took to create the buffered bitmap and get a DC to it. On my Fenix 7S Pro, that was 8 msec (first time, second time around, just the DC was fetched in 0 msec). Knowing that building the whole graph with 2107 / 9 data elements (234) to plot took 2 passes, first one took 902 msec and the second one was less than 50 elements (216 / 9 = 24 elements were plotted) so maybe around 100 msec, that's about 1% overhead took creating the buffered bitmap, I don't think I'll waste time trying a different method as it works quite well.

0:43:07 : Drawing graph
Creating buffered bitmap took: 8 msec
0:43:07 : Drawing graph with 2107 elements, mSteps is 9
Overhead before main loop: 53 msec
50 passes in 251 msec
100 passes in 455 msec
150 passes in 653 msec
200 passes in 850 msec
0:43:08 : Stopping after 902 msec at index 216
0:43:08 : Drawing graph
Creating buffered bitmap took: 0 msec
0:43:08 : Coming back at index 215
0:43:08 : Drawing graph with 2107 elements, mSteps is 9
Overhead before main loop: 25 msec
0:43:08 : Graph drawn, requesting to show the result