OSDev.org

Hi Mates

I've been out some time.. but now i'm back with my OS. And I'm trying to build a GUI uppon my kernel. And I read in the past some threads about this. My question is more an architecture than algoritmic, how you exposed you graphical API to user applications?

Do you use RPC? IPC? socket? (which is faster?) I know it depends on the core desing of my GUI: I don't have completed it yet, and i am wondering about this. As it will be event driven (the gui part), should the kernel/gui core control anything or the app?


Thanks!
Alberich

I have not started my GUI yet, but in my opinion, a directly callable interface (syscall, etc), plus IPC mechanism for uploading "texture", and then build a socket proxy on top of that if remote desktop is needed.

Asynchronous communication has a much better performance potential compared to synchronous ones as both the client and the server/driver can perform in parallel in such a design. However, this is very OS specific and need not at all be visible to the user.

In addition, you want to transmit the least amount of data without spending time generating that data from actual implementations. The functions, states and operations that come from there are what actually define your API as visible to the end user. How those are mapped to system calls, socket writes or memory buffers is typically performed by a library, which is also the place that deals with making remote screens and such transparent to the user.

I suggest to study X11 protocol. It cloud look hard for the first time, but later it will pay out. (Not to mention compatiblity).

Basic scheme is this:
1. client calls drawing functions in userspace library that generates buffered tokens
2. tokens are sent from client buffer to server with a syscall, just like fread/fwrite (can be socket, pipe, IPC, RPC whatever)
3. server decodes tokens and applies to a hidden pixelmap
4. if the pixelmap is the focused window, it also exposes it to screen via video device driver

It can also be used other way (user input or window resize for example) to inform the client about events on server side.

turdus wrote:I suggest to study X11 protocol.

Only if you study its downsides, too.

Solar wrote:

turdus wrote:I suggest to study X11 protocol.

Only if you study its downsides, too.

But of course. I never said that tokens were carefully chosen or elegant in X11 For example the fact that a display and visual are black and white by default is ridiculous nowdays. I meant the way an application, the gui server and the video driver communicate with each other.

Sorry, I moved to a new flat and i was without internet.

X11 is an option, but as it is the only one I know i was trying research in other ways to do it.

Combuster wrote: In addition, you want to transmit the least amount of data without spending time generating that data from actual implementations. The functions, states and operations that come from there are what actually define your API as visible to the end user. How those are mapped to system calls, socket writes or memory buffers is typically performed by a library, which is also the place that deals with making remote screens and such transparent to the user.

I didn't understand what you mean, sorry.

But I was interested in something more asyncronous, like comsbuster said.
Any idea on how could I get soma basic interface exposed to end user? (without details, for the moment i want the ideas)

How windows, beos and mac do that?

Thanks!

alberich i could send you a electronic copy of some of the Amiga Documentation or the Copland documentation if your interested.(both are well over a decade old...)
It seems only the file system on BeOS was very well documented, since i cannot find the rest.(perhaps i am looking in the wrong places)

X11 is a interesting system the original Unix creators see it as a hack on, hence Plan9.

berkus wrote:Windows and BeOS are pretty direct. MacOS uses Core Graphics (also Quartz, Core Animation) - you can read about those in Apple documentation.

You read about PicoGUI, Fresco/Berlin and other experimental servers, too. Use Wikipedia.

What means direct? which mechanisms they are using?

CrypticalCode0 wrote:alberich i could send you a electronic copy of some of the Amiga Documentation or the Copland documentation if your interested.(both are well over a decade old...)
It seems only the file system on BeOS was very well documented, since i cannot find the rest.(perhaps i am looking in the wrong places)

X11 is a interesting system the original Unix creators see it as a hack on, hence Plan9.

Cool, if you don't mind send me please. [email protected]
I looked for haiku instead of beos, as beos filesystem only has dominic's book and in some ocasions is not quite acurated.

But for the moment i'm only look for ideas and different ways of doing it.


thanks boths for the reply

In other words, you might want to do some actual research into how all current platforms work. That's much faster than being able to ask two simple questions a day and getting short answers because the people don't have more time than you.

Thanks for the answers

Just for the record, I was not planning to get the magical solution from here.. only people opinions.

things like you feel rpc better? rpc into the kernel, outside? etc...
or more concrete ones: what do you thing about controlling a window render buffer? application has the buffer which is copied by the manager? or the manager has it, and makes it available to the app?

Just opinions,.. not magical answers. I'm not here for you to build my os, i'm here becouse i like doing this kind of research and exchanging info.
sorry if it seems the opposite.

Alberich

Anything synchronous has unavoidable scaling issues. For the rest, the implementation of the data transfer is a detail and does not really influence neither performance nor how a programmer sees it. Every fancy term you see is just another description of IPC - either synchronous or asynchronous - and therefore is not a meaningful discussion.

Many of the buffer things are the same thing. In all cases data has to be transferred from one end to the other. If this happens efficiently people are happy. How this happens under the hood is something end users don't really want to care about.