graphics context smashed

[ginge]

neographics nGContext, the main drawing context in RebbleOS is shared between two draw threads. This can potentially cause issues. The context is created in the overlay thread, the first draw thread to run. This is not ideal.

Create

• A better mechanism to create nGContexts per thread (add to app struct?)
• allocate the nGContext to app_malloc by changing the NGFX preferred malloc settings to app_malloc
• clipping/rect support in neographics.

===== Old description neographics context is created in app_malloc on thread start. This could cause an issue where the overlay thread is using the draw context while an app is loaded. The app loading deletes the memory that drawing requires.

Allocate the context at the global level (will require changes to ngfx) or statically declare this

see appmanager.c:598

[Helco]

I would propose introducing multiple context instances, so the app, overlay, OS, etc. all have their own n_GContext based on the same framebuffer. If locking the framebuffer to only one writer is necessary, we could use the already existing parenting feature (meant for PebbleOS), which uses graphics_capture_frame_buffer of the parent context. Additionally this approach would help in:

• A not yet documented issue of overlay setting context attributes (e.g. fill color) and thus changing the drawing of the app (and vice versa).
• A proposal for the future would be to move the clipping out of RebbleOS to ngfx and allow for an easy way to implement layer_set_clips and prevent the app messing with the area of the overlay

[ginge]

Locking shouldn't be a problem for now, but a good idea. Due to the way that the main app and overlay are drawn, it shouldn't be possible for an app to draw over the overlay. We draw in this sequence: App/Overlay draw request => app thread draw => overlay thread draw. it means a full page layer re-draw from app when overlay changes, but that's ok. We need to be mindful of the overlay rect changing, such as reducing in size, thus requiring a full app layer draw. Currently this is a requirement that all layers re-draw. It's just simpler.

I agree with all of your suggestions! (especially the fill colour issue! good find) It would help to break the draw chain above to become a little more async. But with the minor challenges of frame by frame rect changes. Related: A per thread context would help with my preference of the draw x,y offset handling to be done in ngfx. Such as setting the offset in the context before draw commands. I'm sure theres a more elegant way to do that.

Good feedback

[ginge]

Resolved by 8314dde888cbbf66197c944b49a220d1402a43ad