OSDev.org

@pype: your question about per-primitive-clipping has brought me to the idea to at least convert the FILL_RECTANGLE function to something which calculates areas to draw ere it executes (i.e. looks what inside the given area to fill fits inside a given clip. If nothing is inside the clip, bail out, continue with the next clip)

... btw, is the Xserver responsible for clipping stuff?

@candy: No, it hasn't been that. It's been some small, slimy bugs easy to be overseen even by the most experienced programmers *rofl*.

---> continued ranting ...

Now, an other Idea springs into mind:

what about the following:

We keep the clips connected to the windows and also globally connected in a circular list. So upon clip lookup, the server can easily access the clip list instead of traversing the windows and querying for clips. also I'd store info about: who owns a given tile. we'd also store information about who has caused the intersection. (window above)

Thus we'd maintain a list of tiles of the screen.

upon moving/vanishing a window, we query the list for: with whom we have intersected: redraw it (with recalculation of the clips)

Then we'd refresh the screen (update the affected area).

It sounds ugly but cool currently - so lets check if it works s expected ...

stay safe

The first step to improve gui performance is promising. To make the fill rectangle function clipped with memset sped up the thing by factor 200 *rofl* THAT slow it's been, imagine! just a bit of calculating then the memset et voila!

It has some flaws that make it bail out, but these I'm about to track down in the coming hours. But I tell ya: as pype says, to have some primitives perform the clipping before drawing anyp pixels - boosts performance immensely.

sure it does... "putpixel" is certainly something GUI developers should avoid, simply because setting up parameters eats up cycles.

And what you can do with rectangles can also be performed with lines (e.g. split LINE(x1,y1)-(x2,y2) into LINE(x1,y1)-(clipx,y_func_of_clipx)) or circles (well, that may be more complex, though), bitmaps, etc.

i'd personnally bound each "clipping region" with "drawing target" memory so that you could differentiate window areas that will write directly to screen from areas that will render in some back-buffer for later alpha-combination with other data, etc.

@pype: that's why I've revised the stuff.

circle & font drawing stuff will remain with a clipped put_pixel thing for now.

Gonna add some twists and tricks to the gui service/video driver combo today evening.

There is good news and bad news. Letz start with the good news: Full blown window dragging is back. the bad news: It's a bit slow in qemu (vmware is way quicker at hands) and without decent hardware acceleration stuff. That's due to the still not so good clip management stuff. I need the global map of visible clips and to whom they belong - this way, I can say to a window: hey, redraw this clip, it's been obscured. It can lead to quite some speed up.

What I'm going to do next: Window resizing. also with redrawing the window in the meantime.

But for the sake of not overstressing the User&his cpu: I'm going to add a settings application. It will f. ex. contain a tab for global gui settings: button color, border color, title bar color,... and some tweak settings (checkboxes) draw full window on drag, draw full window on resize - so the gui either draws just an outline upon window dragging/resizing or it draws the full window - keeps the content.

Let's see what comes along there

Stay safe.

PS: i should take ata and hard disks into considerations. floppy space becomes less and lesser the more applications I'm building. *gg*

if i can afford a few rants ...

window moving

This is a very specific operation. While the user moves a window, it does not do anything else, so virtually any other operation is freezed. The simplest solution to this problem is to capture the state of the screen before you start the move and then move step by step.

If it takes a bit longer to display the first movement, that's no problem. The user will perceive that as a "resistance" from the window, which is simply natural in realworld and won't perturb anyone (when moving a large crate, you have to push it a while before it starts moving, right ?)

What you should avoid is those ugly repaints behind your window at every step. Especially, you should have a *single* screen update with the new position of the window and the exposed content of back windows. Also avoid to repaint the moving window: just grab a snapshot of it and move the snapshot along.

If you can afford it, anticipate moves. If the window moved left by 5 pixels, asks the window beyond to repaint 50 pixels, not just 5, so that you can smoothly render the remaining of the move later.

resizing windows

avoid repainting the window here too. It just takes *ages* and it's not even nicer. the "xor-ed box" is the best technique so far. If your window contain separator panes, etc. maybe you can sketch them too so that the user "sees" how it evolves. So resizing a multi-column spreadsheet could (for instance) show how columns will react (shrinking, being dropped after a certain amount of time).

Thanks! Cool input.

as for the window moving: My former solution 's been to copy the active window directly to framebuffer memory and have it float above the other windows. upon move: restore back the content of the back buffer, put the window to new location (saving the background) and expose area.

I can quickly build such a behaviour into the new approach too: redraw the back buffer content, put the active window to the new location and expose the *affected* area. This would eliminate the need to redo clipping calculation at each movement. It would maybe use up some memory for the window to move and the background saving. (set aside one momory area and operate with it - waste some memory for gods sake) Or I 'd simply put the active window directly to the framebuffer.

Just /dev/brain rambling around in the box ...

uh ? did it was locked by mistake ?

this discussion include alot of usefull information about GUI. I am not a good Graphics programmer, therefor I don't understand well what is clipping ...
it will be more usefull if could you point me to book or side which describe graphics operations like clipping and bitblt and so on.
I have started to get VESA support to my kernel thus I am ready to get dive on graphics operations.

BTW:
As I said I am not now good by grahpics although I am a developer in Xorg ;D. Xorg has alot of parts other than do graphics operations. you can said there is not alot of work now on Xorg about using software rendering. Xorg has a library named frambufer libfb.a which do all this graphics operations related to painting on framebuffer and for years hasn't got changed alot. if the graphics card has 2D accelations functions then it get called, if not presented then "fb" library will handle it.

look at chris gieses web site: http://my.execpc.com/~geezer/

He's got his taliesin gui lib somewhere under "free source code". I've designed and expanded my clipping stuff with his ideas in mind.

You can also peek into the source of my os - namely the directory "gui" will be of interest for you.

thanks for the link.
where can I find your OS source.
actualy I want also to experement with vector graphics, because it can be decribed mathemeticaly and can be easly extend to 3D later.

Sorry, have forgotten to indicate it:

http://www.distantvoices.org/

under 'blueillusionos'

It's not the latest source tree but should give you quite some hints about how to do it.