OSDev.org

Hello Everyone,
I've written custom scrolling routine for 1024x768x32bpp VESA video mode. It scrolls 25 lines up but is very slow while implementing on the real hardware (though works fine with qemu and virtual pc). Here's the code:
The First thing I'd like to ask is that does VESA have built-in support for scrolling (without using interrupts)? And of course, if somebody knows the faster way to implement scrolling the screen, please help me with that.

Best Regards,
Chandra

You could memmove the data up a line and blank the bottom.

-JL

Hi,

Chandra wrote:Hello Everyone,
I've written custom scrolling routine for 1024x768x32bpp VESA video mode. It scrolls 25 lines up but is very slow while implementing on the real hardware (though works fine with qemu and virtual pc). Here's the code:

Code: Select all

void scroll_screen_up()
{
unsigned long x=0;
unsigned long long *vidmem = (unsigned long long*)frame_buffer;

while(x<=393216)
{
	x=x+1;
	
vidmem[x]=vidmem[x+12800];    /* Valid only for 1024x768x32bpp */	
}

}

The First thing I'd like to ask is that does VESA have built-in support for scrolling (without using interrupts)? And of course, if somebody knows the faster way to implement scrolling the screen, please help me with that.

Best Regards,
Chandra

There was an RFC for hardware bitblit and cursor support in VESA2.0, but it never caught on and no graphics cards implement it. So unfortunately, no.

This just leaves other ways to tune your code - some hints:

* Writing to video memory is VERY quick. Reading from video memory is VERY slow. Try to avoid reading as much as possible.
* For your memcpy example, this means the most efficient way to do this is to store the framebuffer's contents shadowed in main memory, perform the memcpy/memmove on that, which will be fast, then just write the resulting buffer back to video memory. This way you only write to video ram, never read.
* You're doing a 64-bit copy on a 32-bit processor (use of long long) - this will be slower than the equivalent 32-bit copy.
* Just for code quality purposes, your code would be better written using a FOR loop. And avoiding magic constants.
* Consider using an optimised memmove - an optimised C memmove can be found in the Pedigree source (please keep copyright headers), along with several tuned ASM variants.
* Enable write-combining.

James

Hi,

JamesM wrote:There was an RFC for hardware bitblit and cursor support in VESA2.0, but it never caught on and no graphics cards implement it. So unfortunately, no.

I haven't seen an RFC; but VESA did publish (and adopt) "VESA BIOS Extension/Accelerator Functions" (or "VBE/AF"), which covers vertical sync and page flipping/double buffering, hardware cursors, 2D bitblits, and 2D acceleration (lines, rectangles, triangles, polygons). Of course VBE/AF never caught on, and (almost?) no video cards support it...

Chandra wrote:I've written custom scrolling routine for 1024x768x32bpp VESA video mode. It scrolls 25 lines up but is very slow while implementing on the real hardware (though works fine with qemu and virtual pc).

For smooth scrolling, you could try using "VBE function 07h - Set/Get Display Start" (which was introduced in VBE 1.2, and is a required function for VBE 2.0). This will let you scroll around in a certain area without doing any extra reads/writes at all. If you need a larger area, then you could also use this function to avoid reading/writing as often (e.g. only update display memory when you reach the limits of how far "VBE function 07h" will let you scroll).

However, I'm guessing that you're scrolling something like a boot log, and that you're doing it in protected mode (where you can't use VBE). In this case, follow all of JamesM's suggestions.

Also, one of the tricks I do is have some read-ahead. For this to work you'd need separate routines for adding text to the boot log and for the code for updating the screen. For example, other code calls your "addChar()" and "addString()" functions (which just append characters to the boot log in memory - a big ASCIIZ string if you like), and when it's ready it calls your "updateDisplay()" function. The "updateDisplay()" function checks the boot log to determine how many lines to scroll, then scrolls the screen once (if necessary), then adds the new text to the screen. This way, in some cases the scrolling can be skipped entirely. For example if the screen can display 48 lines of text and someone adds 60 lines of text to the boot log before calling "updateDisplay()"; then you can just clear the screen and display the latest 48 lines of text (instead of doing the "scrolling by one line" 60 times and drawing the full 60 lines of text). Of course if they add 10 lines of text then you scroll once (instead of scrolling 10 times), which is only 10 times faster.


Cheers,

Brendan

Brendan wrote:However, I'm guessing that you're scrolling something like a boot log, and that you're doing it in protected mode (where you can't use VBE).

Your guess is exactly true. I've got a very huge bootlog and before you say, I've already allocated some space for saving whole the bootlog.The only difference is that I know the end of the event in the log by checking the \n character. Whenever, \n character is encountered it means certain event is completed and whenever \l is encountered, it means whole bootlog is finished. This simplifies in retrieving the log later. Anyway, I'm currently adopting JamesM suggestion so let's see how it works.

Best Regards,
Chandra

Well, JamesM suggestions worked. As he said, reading from the video memory is slow so, I am currently creating cache of the visible video memory in Physical Memory and then when required, read from that location. This is approximately 3 times faster.
Thank you JamesM.