Windows

This topic has been imported from the old forum. Due to its use of fixed format text, you may need to make your browser view wider in order to see posts with the correct layout.

And while we are at it, we should utilise OpenGL for drawing things on the screen. This would make it so much easier to introduce graphics acceleration.

And while we are at it, we should utilise OpenGL for drawing things on the screen.

I think the logical place for this sort of thing would be on the HAL graphics interface, GraphicsV. That would allow a software-based renderer to implement the graphics primitives in the absence of accelerated hardware, in a way that fits in with RISC OS conventions.

One problem we faced with the Iyonix graphics drivers is that it was impossible to replicate the RISC OS diagonal line algorithm, or the GCOL modes (AND/OR/EOR plotting) so a software fallback was needed in a lot of cases. I don’t know if this situation has changed in recent years.

But if we used Mesa, we would not have to write the drivers for all the possible GPUs ourselves. And if the window manager used Mesa to render things, it would also make it easier to implement some cool visual effects, like in compiz or MacOS X.

What I’m saying is that using a RISC OS vector gives us the opportunity to support hardware which isn’t supported by Mesa – many of the ARM-based system-on-chips which RISC OS could easily be ported to don’t have a separate GPU like conventional desktop machines. It also gets round licencing issues: you could have a Mesa claimant which is open source in a different module from a closed-source graphics card driver.

Hasn’t someone already ported an OpenGL implementation to the Iyonix with accelerated functions for its nVidia graphics card?

...Ah, yes. Simon Wilson’s port. Here it is:

http://www.simonrules.com/iyonixmesa/

I think it builds on David Boddie’s earlier work:

http://davidb.drobe.co.uk/

How does that kind of effort compare against the kind of thing you’ve got in mind, Julian?

On Castle’s 32 bit pages there is some documentation on GraphicsV. It suggests that only block fills and copies are accelerated, is this the case or is the document incomplete?

is the document incomplete?

Looking at Hdr:GraphicsV, I think the Castle 32-bit pages are complete. I’m obviously thinking of work that we were going to do but never got round to. That’s something to add to the wishlist, then, along with inverting rectangles (so that Paint isn’t so slow when you drag out rows/columns to add/remove).

How does that kind of effort compare against the kind of thing you’ve got in mind, Julian?

What I had in mind was a window manager that utilises IyonixMesa to render window contents and furniture to the screen.

Let me first say, that I have not done any extensive software development in about 8 years, when I moved my focus to Linux/Unix/Windows/RISCOS/MacOS network administration and media (mostly web) design. I have never really done much programming on RISC OS, because back then I much prefered the nice IDEs with integrated version control and database connectivity available on other platforms. So please forgive me for any inaccuracies, omissions and errors, and correct them where needed. Also English is not my native language. This pragraph was especially aimed at Peter Naulls and David Ruck. ;-)

AFAIK currently on RISC OS whenever one window is moved across another window, the lower window has to be redrawn by its application as it re-emerges from below the top window. And a window wich was partly off the screen, has to be redrawn by its application as it is moved back into view. Same goes for iconised windows. Small windows, wich only display part of a document have to be redrawn by their applications, as the user scrolls through the document or enlarges the window.

As long as the window’s content is static (like a photo, PDF or PS file, a drawing or a text document), as opposed to dynamic (like web pages that adjust their layout to fit the window size or animations/movies), this is a total waste of CPU time. These tasks could be performed by the graphics hardware. The windows’ full rendered contents could be kept as sprites in the RAM on the graphics card and the GPU could take care of the redrawing.

IMHO the best way to do this is to handle the desktop like a 3D scene in OpenGL, where each window-sprite has not only x and y coordinates, but also a z value. This way OpenGL (accelerated by the GPU) handles all the redrawing and hiding of window-areas and the only time that the applications have to redraw anything themselves, is when their window-content changes.

IIRC ViewFinder did something similar by itself (without OpenGL) and was thus tied to some very specific GPUs. However by using an OpenGL implementation like Mesa, this could work on all graphics systems, because there is always a pure software driver available for simple screenbuffer devices and not-supported GPUs.

Most modern window managers on other platforms work in a similar way. And once the desktop is an OpenGL scene, one can easily incorporate cool effects, like wobbly windows, windows that shrink down when iconised and are blown up when re-opened, as well as really useful, key-press activated effects, like shrinking all windows down enough so that they can be displayed side by side to select one from the stack, move them all off the screen so one can get at things on the pinboard, stick desktops on the sides of a cube and switch between them by rotating the cube.

Open a few windows on MacOS X 10.4.x and press one of the F9 to F12 keys on the keyboard, to see a few those things in action. Others are taken from Compiz, wich you can see on SuSE Linux 10.2 desktops.

Anyway, I’d like to go on, but I have to prepare for a wreck-diving weekend on the Mikhail Lermontov now. :-) So feel free to rip this wish apart until I’m back in about four days time.