"Let's talk 64bit" presentation at ROUGOL next Monday, 19th August
Pages: 1 2
David J. Ruck (33) 1635 posts |
RISC OS is slower on the same hardware even for single threaded code, because it can only use a single core. With single thread code on a multi core OS a lot of house keeping tasks are being done on the other cores, not interrupting the processor or putting pressure on that core’s cache. RISC OS also hates memory, it would rather leave gigabytes sitting around unused than dare use any of it for caching. As RISC OS is really a single tasking MOS with a bit of task switching bolted on at the GUI, one way to get pre-emptively multi-tasking is to basically run a separate instance of the OS for each application, composite all the windows on to the display, and the only tricky bit to implement Wimp message passing between the instances in a way that doesn’t block the entire desktop if something isn’t responsive. |
Piers (3264) 43 posts |
All modern browsers render into layers often of about 1.5 times the size of the window (if they’re a scroll region). The bitmap is plotted on the main thread by the GPU (very smoothly), and the browser hopes to have rendered the next tile in time on a background thread (the same thread that executes Javascript). That’s why when loading a page and scrolling you often get white (often cutting across a line of text, since the bitmap size is a convenient power of two, rather than aligned to text baselines) – the page hasn’t been able to render in time. Once the page has loaded there’s usually enough CPU to poll regularly enough. Until a few years ago they rendered a chequerboard, but these days they render whatever background colour is in place. It’s not dissimilar to Google Maps’ tiles, except the lag is much less as it’s rendering to the tiles rather than loading them over the network. Given the GPU does the compositing of the layers/tiles, there’s almost no work to be done by the CPU when you scroll a few pixels. You need to scroll the height/width of a tile before it throws away the top tiles and renders into the next ones. |
Piers (3264) 43 posts |
icloud.apple.com is far more impressive (and far newer) than Google Docs. Apple Pages always reminded me of Impression, but in a web browser. Even on the Pi400 (PiOS) it’s nearly usable, though not quite. Pi5 is lovely (though obviously not Iris-able).
Hmm! Recursive MOS instances for when you ‘fork’. |
Simon Willcocks (1499) 513 posts |
Tried that, it doesn’t work. There are callbacks, service calls, vectors, and event handlers all over the place; there’s no way to get them to the right modules, etc. |
David J. Ruck (33) 1635 posts |
There’s obviously going to have to be a bit of low level plumbing to get around that. |
Simon Willcocks (1499) 513 posts |
You know the black ship from the Hitchhiker’s Guide to the Galaxy? I’ve decided that the best approach is to leave RISC OS alone as much as possible. The Wimp is modified to use a multi-tasking kernel, replacing the AMB part. Legacy software is given a single SVC stack and only one task at a time can make legacy calls (essentially the current Wimp task). (The code will be running on whatever core is free at the time.) Everything else uses pipes and queues to communicate with other programs, files, network, cameras, interrupt handlers, etc. Almost everything runs in user mode, with SVC just for inter-task communication. Wimp_CommandWindow will essentially go away, maybe replaced by a modified GraphTask? Task windows be replaced by a simple Wimp program that will communicate with its subtasks using their input and (maybe two!) output pipes. |
Pages: 1 2