-
Notifications
You must be signed in to change notification settings - Fork 2
MultiprocessingWimp
No matter what the technology used to implement the desktop, there is only ever one human using a RISC OS computer at a time. To keep that person happy, the existing Wimp cooperative multi-tasking model is ideal, except for occasional delays in screen updates or, even worse, sound.
Audio output is not managed by the Wimp, except that a task will have to be swapped in to buffer more audio, and that can be delayed in the Wimp.
Video output is absolutely managed by the Wimp, but that doesn't have to mean tasks can't update the screen in parallel.
A simple approach that should work consists of a normal Poll loop, with idle and a poll word, and a display thread which will request updates to the task windows as they become necessary.
The poll word can be used to wake up the Poll loop, if a window needs to change size, for example.
When Wimp_UpdateWindowBg is called, the window stack and a graphics context (there's one per core) is locked until the final Wimp_GetRectangle has returned indicating no more to do.
Intercept the new Wimp_UpdateWindowBg SWI and perform the above locks. Also, intercept the results of Wimp SWIs returning screen rectangles (RedrawWindow, UpdateWindow, GetRectangle), and save the rectangles for each window for returning in response to Wimp_UpdateWindowBg.
The list needs to be cleared when the window stack has changed.