*hm* ... Video Driver and Gui Server Interaction - Flickerin

[distantvoices]

Hi!

Logged in again I am. Sometimes it happens to me that I am not lazy at all.

These last days I've implemented some GUI basics in my kernel - driver - servers combo. I imagine, it would be far easier to handle in monolithic kernel environment, but for the thrill I am seeking I've decided to stick with micro kernel design, and so, the video driver which executes in kernel space and the gui server, which operates in user space, are two separate things: One executes (Video driver) and one manages (gui server).

Now, several big problems arise: 1. The active window: shall I draw it in gui server memory in the buffer or shall i have the video driver draw it as the very last window directly to frame buffer memory. Here comes the second problem: this damned thing flickers as if going insane. Even with the famous wait for vga retrace the flicker doesn't vanish, especially for BIIG boxes. Damn it. So, the choice to draw the whole thing into a buffer and then flush the buffer would be the most reasonable thing to do? Or shall I tie the video driver to the gui server whilst moving windows? execute it in the gui server adress space and just flip around some pointers and flush a buffer finally?

I don't have problems with memory allocation: this runs as smooth as one expects it to do. Just have to do some fine tuning (the message passing grabs the chunks of bigger memory too often and krealloc doesn't get them for the windows). Nor do I have Problems with text output. No useable api yet, but my shell user processes take the input as usual and just print it to the console. this output is rendered on a text window.

Your hints and tips would be appreciated.

stay safe

ps: @Offendi Yoda: With Happyness in my Heart I receive your words for they assure me that I 've got a task here :p.

[Pype.Clicker]

First, keep in mind that in most windowing systems, you did not see the content of the window you move: you just see a moving lined box around (remember Win98 ?)

Second, while you move a window, the rest of the GUI system does no longer update, so you can safely assume that the GUI server has 2 modes: the "normal operating mode" and the "arranging windows" mode. Doing this assumption allows you to handle window movements independently of any other thing, and (for instance) assume that the background is constant. Look at how enlightenment can handle this:

• you click on the title bar to start moving the window: the window is raisen on the top of the screen and exposed, so that you'll have a "fresh" image of it.
• 2 snapshots are taken: one of the window and another one for the whole screen.
• when moving the cursor, all you see is the displacement of the window's snapshot above the whole screen's snapshot. No "expose" events are sent at all, and the window's snapshot is even made translucent (which comes virtually at no cost with MMX
• at last, when you drop the window to its final location, expose events are sent to other windows so that the screen portion that was previously shadowed by the moved window repaints.

Imho, this is the best way to do. Look at gnome/kde window managers on the other side: at every mouse movement, you see the screen repainting beneath ... ugly artifacts (you know what tastes are).

[Pype.Clicker]

now, about VideoDriver vs GuiServer, it'll be up to you to know at which level you want to make them interact.

You could have a very low-level video driver that just has a "framebuffer-like" interface: it exposes its memory to the GUI server and just offer mode switching and reporting features. In this case, the flickering avoidance needs to be handled at the GUI server, for instance by the mean of a double-buffering technique.

On the other side, you could imagine that the video driver itself has the ability to deal with "window buffers", doing clipping, bit blitting, etc. All the GUI would do is paint within a window (according to high-level commands sent by users, rendering fonts, unpacking jpegs, etc.) using the buffer offered by the video driver and then let the video driver know where the window must be placed, and how it should be clipped against other windows, etc.
In this case, when the window is moved across the screen, all the GUI server need to do is sending location updates to the video driver which will then perform the adequate operation to make it flickerless
(using hardware acceleration, making every window a textured polygon, whatever

[Xardfir]

Hi Beyond,

I had a flickering problem when implementing a TUI (Textual User Interface - multiple windows, event driven) a few years back. It didn't matter if I was writing to a window or not - everything would just flicker.
I finally found that the problem was that my video manager was updating each window (during retrace) whether it NEEDED updating or not.

To fix it, I put in a flag in memory for each window to say if it had been written to or not. If it hadn't the update could be skipped. If it had then I checked to see if the window (or parts of) were covered and only updated that part when necessary.
The result was a vastly improved response time from my TUI (less memory moving) and no flickers.

Hope this might help.

Xardfir.

[Pype.Clicker]

still no reactions from Beyond Infinty ... maybe he lost his thread ...

Wake up, BI . . .
The RealWorld has you . . .

if you have further episodes of BI in "the GUI: reloaded", let us know

[BI lazy]

*beam*twooonnngggg...*

*backfromrealworld*

Sorry for not having replied; indeed, real world needs and real world aspects have drawn my attention upon them. Got some big project laid into my hands which is of course to be done yesterday, so: WOOOORK is on the way.

Regarding the thread: I am working bit for bit on the box-moving-agenda, meanwhile trying out your proposals. Comparing to this, implementing a store-and-forward-async-messagepassing-system in the kernel has been a Walk In The Park(tm).

And beside this, I am on the way of developing a kind of piping subsystem: one process writes data in a buffer and tells the other one to fetch it, when buffer is full or EOF. The reading process tells the writing one to hand out data, when the pipe-buffer is empty. just like this.

May the Schwartz be with you and thanks for feedback.

stay safe

[distantvoices]

aaahhh.... finally, I've found kinda solution to my problem: painting on the double buffer and repainting the changed area to the screen. This comes along with only one waitfor-vertical-retrace and only one repainting action and it is a good-thing(tm).

I gonna do some double buffering with the mouse too to avoid the extra repainting of the mousepointer too... with the method I've found out, it should do swiftly:

1. do the maths (calculating offsets, offset differences, movements and displacements)

2. perform the painting in the double buffer.

3. flush the changed area onto the screen with one and only one function.

Of course, I still have to do some fine graining things. bit blitting would be one of them. but for now, I am rather satisfied and kinda pleased.

How will this gui stuff be done in my kernel? Well, As usually in microkernel design, I try to perform a split between management and Execution. the gui service is responsible for painting windows, doing the clipping and intersecting between windows (eventually handling mdi-window structures - window inside of another window), placing wdgets and controls according to the clients commands. and then, it tells the video driver to take the data and copy it to the screen - and to the video double buffer. -the videodriver is furthermore responsible for the window moving stuff. It moves themouse - it also moves the active window. I think, the video driver will also be responsible for drawing text ... this way I do it at the moment. I could also have the gui server as well as the user task fetch the typed chars - the former for output, the later one for fetching the input. It would just require some more messages (to the gui server). but would it be performant enough for smooth responsability?

Stay safe and ... no, i didn't forget about this my thread. )