OSDev.org

What is the fastest way to update the VGA working with OSM and LFB?

The first method is to periodically write all OSM buffer to LFB (for example every int 0 fires) if a window/process/etc requests window update/repaint.
The second method is to update only the part of buffer that has changed.

Logically the second method is faster.
But if you have 20 windows that makes non-stop repaint and repeated mouse moves, maybe is slower.

For now i use the first method that is more simple.
I make all changes in OSM and every int 0, if needs repaint, i copy all buffer to LFB.

Any advice ?

You could use a hardware cursor, that saves you from redrawing every tiny movement of the mouse. Otherwise, you could provide for that feature in software, that the mouse isn't ever drawn in host memory, but only when data is copied to the graphics card.

Combuster wrote:You could use a hardware cursor, that saves you from redrawing every tiny movement of the mouse.

How can be done this in PMode ?

Combuster wrote:Otherwise, you could provide for that feature in software, that the mouse isn't ever drawn in host memory, but only when data is copied to the graphics card.

Mouse is drawn every time I copy OSM to LFB.

Jef wrote:

Combuster wrote:You could use a hardware cursor, that saves you from redrawing every tiny movement of the mouse.

How can be done this in PMode ?

That, sadly enough, depends on the card you have. Which in essense means you have to do some research on the matter.

edit: the original vga doesn't have a hardware cursor

I only know this very easy optimization where you have a "update square" and let it grow every time you draw something on the OSM.

Here my Paint example


This is good for a image based gui but it could be to slower if you change many single pixels.

sounds good.

sorry for the noobish question, but what does OSM mean?

OSM = Offscreen memory

zaleschiemilgabriel wrote:sorry for the noobish question, but what does OSM mean?

OSM = Off Screen Memory
LFB = Line Frame Buffer

isn't it faster to draw directly to the LFB?

Here what i have found, first these no better way than use a hardware cursor, but in most hobby OS's this is not possible.
Now if you try and update screen every mouse movement, at high-res it will be very slow.
Now the best way i have found is to save a square (background) the size of the mouse cursor, from the X,Y of where you are going to draw the mouse, than draw the mouse cursor directly to the LFB, on the next mouse movement you restore the background at the old X,Y and than draw the mouse cursor at the new X,Y (remembering to save the background first).
This is for the mouse cursor only, if anything changers on screen, the whole backbuffer is redrawn to the LFB, than the mouse is redrawn to the LFB.

Now i find it works the best, i do not know how others do it.

If you want to see it working for real, you can try my bootable web browser project.
Here is the NEW self extracting exe to put it on a floppy
http://www.dex4u.com/FBrowser/FBrowser.zip
Here is the NEW floppy image and .bat file to test it in a emulator qemu.
http://www.dex4u.com/FBrowser/FBrowserE.zip

zaleschiemilgabriel wrote:isn't it faster to draw directly to the LFB?

LFB (the memory of VGA) is very fast to write, but is very slow to read.
So its better to use a buffer at the ram for read/write and when you want to refresh, you copy this buffer (OSM) to VGA memory (LFB)

Jef wrote:LFB (the memory of VGA) is very fast to write, but is very slow to read.

Is that still true on modern cards? I know it was on the original VGA. Btw, can't you change the rediculous size of the image in your signature to something a bit more decent?


JAL

jal wrote:Is that still true on modern cards? I know it was on the original VGA.

Yes, especially on modern card it is really slow to read the vram! At last in the VGA modus. And for transparent stuff you have to read the screen memory.
But the true reason why to use OSM (or double buffer) is to avoid flickering.
If you draw something over something else you don't want to see the drawing process itself you just want to see the image at the end.

Osbios wrote:But the true reason why to use OSM (or double buffer) is to avoid flickering. If you draw something over something else you don't want to see the drawing process itself you just want to see the image at the end.

Indeed. I remember the old days, when you had to use Mode X (or the 320x200 equivalent) because writing an OSM buffer to video memory was actually slower than one vertical retrace (1/70 of a second).


JAL