Compositing window manager

At present RO uses a stacking WM. Is it feasible to change it to use a compositing WM?

For those unfamiliar, whereas an app running under a stacking or tiling WM draws directly to the screen during updates, with a stacking WM handling clipping automatically, a compositing WM redirects all screen update to a bitmap, which the WM then blits to the screen.

This is how it’s done on Mac OS X, Windows Vista/7 (with Aero Glass enabled) and several X WMs. It’s how Win7 can give you thumbnail previews on the taskbar, and how “transition” effects work, as the WM is simply scaling a cached bitmap.

Now, I’m not interested in transition effects on RO, but as far as I can see, compositing WMs are a Good Thing. Take the Artworks apple, for example, which takes ages to redraw on a non-StrongARM system. With compositing it would only have to redraw once, and wouldn’t need redrawing every time you dragged another window or menu across the Artworks window. The WM would simply plot the cached bitmap back onto the screen.

The beauty of this is that apps using the Wimp redraw protocol would “just work”. The only thing that might have a problem are things like ZapRedraw, which writes directly to screen memory. A legacy mode may be required for things like this.

Thoughts anyone?

Yes, it’s possible. In fact, it may have been done already, albeit for a project which may never see the source code released (https://www.riscosopen.org/forum/forums/2/topics/227#posts-1406)

Geminus also provides similar functionality (caching the contents of windows), using a whitelist/blacklist to disable the code when dealing with programs which write directly to screen.

Of course it would be possible to support such programs as long as you had a screen-sized buffer and lied at the appropriate times.

You’d need a damn sight more than a screen-sized buffer. Let’s take my Iyonix with 20 desktops (via MoreDesk) and something like 100 windows open. You’d need at least enough buffer for the visible area of all of those windows. That could easily add up to quite a lot of screens worth of memory. Sure, you could shortcut it to only buffer stuff that’s currently on-screen, but a) that doesn’t change the fundamental fact I’ve outlined and b) that’d defeat the point of things being able to easily get a thumbnail for all open windows (e.g. alt-tab or Mac OS Mission Control or similar)…

OK, memory is cheap. Let’s assume we can live with that, but performance could also easily suffer. Right now, only the visible bits within a redraw rectangle for any visible areas in windows are plotted at any given time a screen redraw happens. So a subset of window contents from a subset of applications, leading to a relatively small amount of graphics being written to the screen memory. A compositing window manager would (at certain times) be needing to get all applications to plot the entire visible areas for all their open (and iconised) windows. Things like Mission Control give you a live (shrunken) view onto all open windows (maybe just for the current desktop).

Don’t get me wrong, a compositing window manager with non-rectangular windows and vector-based (rather than bitmap-based) icons and furniture is definitely the way things have gone outside the RISC OS world and one day RISC OS will need this, too, but without lots of support from things like graphics cards (and implementing the difficult, platform-specific hardware acceleration code therein) this is highly likely to suck performance-wise and consume lots more RAM. It would probably preclude running on older hardware like Risc PCs altogether.

RISC OS is lean and mean. That’s why the window manager works the way it does. At some point, you do need to sacrifice some of that in order to move things forward, but it’s always a tricky balancing act. The last thing we want is for RISC OS to be as slow as Linux! Compare RISC OS Pi to Raspbian on identical hardware with identical SD cards… Being small and quick is our USP.

You’d need a damn sight more than a screen-sized buffer.

Sorry, you misunderstood my comment as I didn’t quote what I was replying to. Jeffrey had written:

using a whitelist/blacklist to disable the code when dealing with programs which write directly to screen

To which I replied:

Of course it would be possible to support such programs as long as you had a screen-sized buffer and lied at the appropriate times.

ie it would still be possible to capture output from programs that write to “the screen” if one had lied about where the screen was. Of course one still needs buffers for all window areas (though not the whole work area, natch) and for such difficult apps there’d be the additional overhead of copying from the screen-size capture buffer to the specific window buffer, which is unlikely to to sit well with the reason for the application writing direct to the screen in the first place… speed (sometimes).

Don’t get me wrong, a compositing window manager with non-rectangular windows

Overrated.

and vector-based (rather than bitmap-based) icons and furniture

Woah! Who said anything about that?! I don’t think anyone is advocating an SVG desktop.

The last thing we want is for RISC OS to be as slow as Linux!

I don’t think it would be quite that painful, but it might well look it, as one of the side-effects of capturing redraws off-screen is that long redraws appear to take longer – an option for updating the screen during the off-screen redraw would mitigate that. Otherwise you suffer the hallmark of the pre-empted GUI – the I’m-not-ready-to-redraw white rectangle of uggh.

On the other hand, even when Firefox decides it’s going to freeze up for several seconds, other apps are still running and you still have a useable desktop. Click into Word or Thunderbird and do something else while you wait for Firefox to unfreeze. (A good reason to keep Firefox running on a 32-bit subsystem, even on a 64-bit OS – it can only claim up to 4GB RAM, which means in my Win7 desktop and laptop systems it can never “eat” more than 50% of the physical RAM.)

Disclaimer: I know Wintel-bashing was the “done thing” back in the 90s when the RiscPC was new, the StrongARM was bleeding-edge and everyone thought I was insane for having 128MB RAM in my RPC, but seriously, look at what Windows was like. Win3.1 with co-op multitasking (which was seriously broken). Win95 with alleged pre-emption, which was also horribly broken. Win98, like Win95 but worse. And Windows NT4, which believe it or not was pretty decent, but absolutely nothing that wasn’t written by Microsoft would run on it, because back then, nobody had any concept of “file permissions” and “ownership”. ¹

Anyway, back on topic… ;-)

¹ Actually this was the case for a long time when WinXP was the “current” OS. Which is why a lot of stuff broke under Vista, because it required the current user to be an administrator. At least that’s mostly fixed now. Mostly.

Actually this was the case for a long time when WinXP was the “current” OS. Which is why a lot of stuff broke under Vista, because it required the current user to be an administrator.

Power User (lower than admin)

At least that’s mostly fixed now. Mostly.

Yup, mostly apps that don’t understand permissions don’t start.

Continuing the drift – ARM doesn’t have virus problems, this is well known. Unfortunately the hackers know nothing as the Register article shows.

Nope, power user wouldn’t suffice for some apps. One example that springs to mind is the Kodak Easyshare software. One of my clients had a digital camera that used this. You had to be logged in as admin for the software to work, Power User would not do.

Needless to say, her PC ended up riddled with viruses. As well as having a lot of unauthorised software installed on it. I spoke to the MD of the company, and we decided “one strike”. Her local admin access was revoked, and she was provided with a memory card reader instead of the camera dock.

The whining and complaining subsided after a while.

We’ve got another problem at the same site. A piece of software which insists on installing itself under drive C:, not in Program Files. Of course, all their computers have Applocker enabled to avoid virus infections. Which means that basically, it didn’t work. At least until I put an exception in to allow the software to run.

Even so, it’s not perfect. One of the reports it produces attempts to create a file under “Office” in Program Files. Of course, on Win7 this isn’t going to happen. Cue me on the phone to their tech support line, trying to explain to them why there’s a variable called TEMP which points to a writeable path. Their response was “nobody’s complained before”. My response – “do any of your other customers run this software on Windows 7 Ultimate or Enterprise editions which are a. joined to an active directory domain and b. have Applocker turned on?” Apparently not. Apparently all their other customers use Windows XP on standalone systems.

#facepalm#

Get a grip guys!

[/rant]

Their response was “nobody’s complained before”

Yeah, I first heard that one while working on medical kit about 29-30 years ago.
So an hour later when the chief tech has phoned all his mates at hospitals spread across most of the middle of the country and has a list of sites who have been told “nobody’s complained before” it’s time for another phone call with a “how do you fancy being blacklisted across the NHS?” opening gambit

Or more recently company install bods who tell me “we always do it this way”¹ as a counter to my version. “my network, my rules” is my fifth² ace.

¹ Along with “our systems don’t do DNS”. This was quite true when he said it, but hadn’t been when I’d checked an hour before. It also wasn’t true when I re-enabled the DNS cache service.
Basically a static IP on everything is easy setup for them and a pain on maintenance for us. I won.

² My rules :)