Buffered Graphics

[Pype.Clicker]

and what, if one does the entire drawing in a buffer and at the end of the operation updates the VRAM in one flush with a memcpy?

i guess it depends on how much you have to update against how frequent your operation are. the more specific you can be at which pixels are modifed, the faster, imho.

[Brian_Provinciano]

You couldn't generally update the screen with one memcpy, but rather, would do something like this (a mode13h style example):

int w = bmp.width, h = bmp.height;
U8   *s = scrBuf + (y*SCREEN_WIDTH) + x, // initial screen ptr
   *p = bmp.buf; // buffer of bitmap
   while(h--) {
   memcpy(s,p,SCREEN_WIDTH);
p += w;
s += SCREEN_WIDTH;
}

If you don't trust the speed of your default lib functions, or just the fact that it does a call for each row, a simple for loop would copy the bytes fine too.


For the xoring rects, all you need are four bytes/words, and a bool or as I use, a pointer to the rect struct to indicate it's set. On window drag, if the rect pointer is not null, xor the region (make it back to normal), then, fill it with the new values and draw the new region. On mouse up, simply xor the region to make it clean again, then null the pointer.

In GUIs for modern PCs, allocating two width*height buffers would work too for full window dragging. Save the window's screen bits to one buffer, then redraw the screen, and save the window's underBits to that. On move, redraw the underbits at their original location, save them from their new location, then draw the window bitmap at the new location, etc. Saves redrawing the whole screen and wasting memory. It's a lot like manual sprite animation.

As for the VESA regs, I've got a great old book I've had for years that deals with all that stuff, from modeX, modeY, VGA, VESA, etc. I haven't done VESA stuff in a couple years, but I'll look it up for you.

[BI lazy]

Hm... I 've choosen the wrong words. That comes if one is too lazy to express himself exactly. I '?ve intended to say:

Update the *affected* region of the screen after all the drawing is done as this is much faster than redrawing the entire screen - that one is laaaaame. *gg*

The moving full windows stuff: I'm doing it as you describe it. move the window in a buffer and only redraw the part that needs to be redrawn.

But I am very interested in the vga-interrupt-stuff, for a.t.m. I do busy waiting for vert-retrace. that's not a fine way to have the videodriver hog the cpu when in meantime other work could be done.

thanks very much

[Brian_Provinciano]

I haven't done my GUIs for PCs because I used them for specific purposes (ie. systems that didn't have GUIs that I needed GUIs for). However, it's all ANSI C (mmmm...I love ANSI C), so I'm going to port it to DOS in the very near future. BTW, the book I was talking about is called the "C++ Graphics Programming Handbook", though it's quite thick , not a handbook at all, heh. It's very good for the lowlevel PC graphics coding that people don't touch anymore because of DirectX.

On another note, my GUIs so far have used messaging systems like windows, with the WndProc, WM_STUFF, wParam, lParam, etc. It's not exactly as windows, but similar--I feel it works fantastic. What about your GUIs? Do you use a WM_STUFF type event handler, or something else?

[FlashBurn]

You guys seem to know what you are doing

I wanto also to start some programing on a gui, but for this project I need some sources for information. From where do you have your information?

[Tim]

On another note, my GUIs so far have used messaging systems like windows, with the WndProc, WM_STUFF, wParam, lParam, etc. It's not exactly as windows, but similar--I feel it works fantastic. What about your GUIs? Do you use a WM_STUFF type event handler, or something else?

I use a similar system, but it can be hidden from the programmer if necessary (the WindowImpl base class calls a virtual function based on messages it receives).

I only use messaging like this for notifications from the window manager; I don't have any function-style messages, which have been shown to be insecure. Instead I use C++ methods in-process, and normal IPC between processes as necessary.

[Brian_Provinciano]

Agreed. It's not too economical to use WM stuff for everything, epecially when certain parameters are used. For example, for a whole bunch of parameters, a struct pointer would need to be sent to the lParam, when a function with the five params could be simply used instead. I also only use the WM for window events such as move/click/button down/list box change/etc.