OSDev.org

Today, I have support for multiple applications running in foreground / background in different video-modes or text-mode. This is achieved with paging, which changes the mapping of the video-buffer to map the LFB buffer to the foreground application, and mapping background applications to a memory-based buffer. When switching foreground application, a save of the LFB to the memory-based buffer is done, and then the new application's memory-based buffer is copied to LFB.

This scheme worked well with the previous generation of video-cards where LFB read/write was fast, but it doesn't work well with newer video-accelerator cards, mostly because the LFB is read.

I think the new scheme will still have the foreground / background concept, but will not use paging to map the buffer. Instead, when an application is executing in background-mode, it will do the same as before, it would do it's operations on a memory based buffer. The difference would be when it is executing in foreground. Then it would do all reads from the memory based buffer, and do writes to both the memory based buffer and to LFB. In order to achieve this, a new selector for the LFB would be used, and then all writes in the code could simply be done in an additional selector at the same offset, reducing overhead of the double-writes to only a memory-write operation. In the switch-from foreground method, there will no longer be a copy of LFB to memory-based buffer (the buffer is already up-to-date), rather only the method table would be restored to only write to the memory-based buffer. In the switch-to foreground method, the memory-based buffer would be copied to LFB, followed by changing the method table to use both buffers.

This new scheme could probably also support graphics accelerations in the foreground application.

Hi,

My general opinion has remained the same for a very long time: Anything that can't be described as "applications send list/s of commands to GUI, which sends list/s of commands to video card driver, where video card driver is responsible for all drawing", is seriously flawed.


Cheers,

Brendan

Brendan wrote:Hi,

My general opinion has remained the same for a very long time: Anything that can't be described as "applications send list/s of commands to GUI, which sends list/s of commands to video card driver, where video card driver is responsible for all drawing", is seriously flawed.

I don't send list of commands anywhere.

OTOH, the video-driver do handle all graphics primitives, and there is a GUI classlib with classes that applications that do this kind of things use. Those are the "command list/s" in my implementation, even if they are handled with API-calls and a classlibary interface rather than as command lists.

I early decided against a typical windowing environment, as I don't think this is the best solution to typical embedded applications I want to support. Instead of applications being started in a window, they get their own virtual LFB (or text-mode) they can use (via the video-driver).

Just remember not to paint yourself into a corner. At some point in the future, you are most likely going to want to put applications in windows. Given that your operating system has been around for twenty years, it wouldn't be an impossibility to say you'll still be around in another ten or twenty. Who can predict ten years into the future? It's a scenario that's likely enough that it is worth designing for.

I agree with Brendan. It's the neatest solution (Applications -> GUI -> Driver), even if it does mean more coding.

JackScott wrote:Just remember not to paint yourself into a corner. At some point in the future, you are most likely going to want to put applications in windows. Given that your operating system has been around for twenty years, it wouldn't be an impossibility to say you'll still be around in another ten or twenty. Who can predict ten years into the future? It's a scenario that's likely enough that it is worth designing for.

I agree with Brendan. It's the neatest solution (Applications -> GUI -> Driver), even if it does mean more coding.

As I wrote above, there is an user-mode classlibrary that more or less is the GUI-part. It contains a hierarchy that starts with TControl -> TPanel / TButton -> TLabel / TScrollBar, TFileView, TTable and probably a few more. Additionally, ini-files can be used for configuration settings, making it a simple "RAD" environment.

OTOH, it is also possible to make applications that draw lines, circles, rectangles, texts, and there is sprite-support. I've also ported JPEG and PNG viewers.

Building real windowing support would require moving the user-mode classlibrary to kernel, or shared DLLs, which I don't plan to do. I also don't have a message-oriented view in the GUI, the only events that exists (key and mouse events) are passed as event methods that can be overridden when making new derived GUI-classes. Then there is the paint method, of course.

Just follow x window system's design is OK.
There is many information about its design and implementation. Eg. microxwin, nano-X

orafy wrote:Just follow x window system's design is OK.

I really hope that was just your bad grammar, and you weren't just praising the X standard. *shudders*

X window system is a hack a patch nothing more it was never intended for the use it sees today.

I've seen a huge rise in remote desktop usage. 4 years ago it wasn't that common but today the suppport is required, if we're talking about desktop like operating systems. With that in mind, when designing a GUI, the remote desktop use case should be in the design from the beginning.

CrypticalCode0 wrote:X window system is a hack a patch nothing more it was never intended for the use it sees today.

I'm not sure what you were trying to communicate here, but I call bullshit.

Out of curiosity. What has it been patched into?

For one, hardware accelerated compositing window managers.

However, usually the fact that a system can do stuff beyond what it was designed for is considered a good thing...

I originally modelled my low-level GUI after PicoGUI (http://picogui.org/). However, since PicoGUI was written in C (and C is not adequate for graphics), and I didn't support C in the kernel, I rewrote it from scratch. But the main design ideas are still from PicoGUI. I have not implemented the client-server model of PicoGUI either and the separation of code and content was reinvented.

And as for remote desktop, there is partial support for this, but it is implemented by sending over properties of controls. That is quite efficient, but it currently doesn't handle pictures, and if a new control is created (which is easy to do), it also needs to be implemented in the remoting system. The remote desktop is also not part of the official RDOS distribution, but it is easy enough to do.

berkus wrote:

rdos wrote:(and C is not adequate for graphics)

I lol'd.

Why else do we have graphic accelerators if C was adequate for graphics?

Up to 1366x768, a typical low-end AMD processor at 1.3 GHz, LFB only is adequate. Up to 800 x 600, on a typical 500MHz AMD geode processor, LFB is also adequate. No need for graphics accelerators. We have graphics accelerators (which have assembly or dedicated hardware to perform the functions) because C is not adequate.

rdos wrote:We have graphics accelerators because C is not adequate.

And we program graphics accelerators in... C