Timer callbacks and multithreading / parallelism / concurrency?

Suppose I have a function for a watchface that runs periodically, controlled by a Timer. Let's call this function "renderLoop". This function does some time- and computation-intensive stuff and draws the results to an offscreen buffered bitmap.

The onUpdate( ) method, which runs every second, copies the contents of this buffered bitmap to the screen buffer.

My question is, which of the following describes how CIQ works:

A) onUpdate( ) will interrupt renderLoop( ) whenever needed (pause execution of renderLoop( ) and then resume after onUpdate( ) completes)
B) onUpdate( ) and renderLoop( ) will execute in parallel
C) onUpdate( ) and renderLoop( ) will only ever execute sequentially (no parallelism or interruption)
D) Something else entirely

In essence, I am wondering if I ever have to worry about a partially-rendered buffered bitmap being copied to the screen.

Right now I am using triple buffering to avoid this possibility, but I don't know if this is necessary. The memory overhead for triple buffering is nontrivial and I suspect it might be causing some crashes on physical devices.

0 jim_m_58 over 3 years ago

Monkey C is single threaded. The timer callback don't run if something else in the app is running

0 nonparametric over 3 years ago in reply to jim_m_58

Thanks Jim.

Following up on this, suppose renderLoop( ) happens to be running at the moment that onUpdate( ) would otherwise get called. Does that mean that onUpdate( ) does not get called on that 1-second cycle? Or is it delayed until after renderLoop( ) finishes?

0 jim_m_58 over 3 years ago in reply to nonparametric

I have no idea what "renderLoop()" is. A function in something you got off the web?

but yes, if something is running when onUpdate() should run, inUpdate() won't run until that completes.

Single threaded.

0 nonparametric over 3 years ago in reply to jim_m_58

jim_m_58 said:
I have no idea what "renderLoop()" is. A function in something you got off the web?

That was explained in the very beginning of my post.

But thanks for the followup.

0 jim_m_58 over 3 years ago in reply to nonparametric

So if it runs off a timer, it will only run when the watchface is in high power mode.So it won't run much of the time. You may want to consider something else, like based on when onUpdate() is called and low/high power.

0 jim_m_58 over 3 years ago in reply to jim_m_58

Remember, in a watch face, a timer can only run for 10 seconds after a gesture.

0 nonparametric over 3 years ago in reply to jim_m_58

The code only needs to run in high-power mode, so that is not really an issue.

The goal of the renderLoop( ) function is to ensure the watchface is responsive and lag-free, despite doing somewhat intensive graphics computations. Copying a buffered bitmap (the end result of the computation) to the screen only takes ~50ms, so logically, copying that one bitmap is literally all that onUpdate( ) needs to accomplish. In that case, the screen redraw will never take more than 50 ms to complete.

All of the work of rendering the bitmap can happen outside of onUpdate( ), in the remaining 950ms until the next redraw cycle. And if the render loop runs long, ideally this shouldn't prevent the next onUpdate( ) from being called, and onUpdate( ) should still be able to display a complete (as opposed to partially complete) bitmap. This is the standard approach to computer graphics in other time-critical settings.

But it does require concurrency (or at least preemption in a single-threaded system), which it seems that CIQ doesn't support.

0 jim_m_58 over 3 years ago in reply to nonparametric

Not sure how you are getting these times, but using getTimer() in the sim is not that accurate, and can vary on real devices. Bear in mind that in onPartialUpdate you only got 30 ms to update small sections of the screen, so displaying a buffererBitmap on the whole screen could take much longer.