How to make a fast PutPixel()?

[flash]

Hi, I'm doing a GUI for my os at the moment.
But I got a problem: How can I write the draw functions like PutPixel.

I want the kernel to draw the screen directly, and don't let the user processes to do this. The draw functions will dirty the graphic buffers of windows or buttons which allocated in kernel memories, but it has to call an interrupt to reach the kernel data, even a pixel function. I think that will make my os run slowly.
What should I do to get the drawing done rapidly and not through the system calls?

[xsix]

make functions to draw something, for example: images, rectangles, ocals etc. For pixels, hm... I don't know any way instead of a call. Just when user app will call it just check if it can draw it or not(eg. if there is a button, dont let to do it

[Mark139]

You could have something like:
DrawingBegin();
DrawLine(x,y);
DrawCircle(x,y,r);
DrawingEnd();

Buffer up the drawing data (operation+params) after the begin and then transfer the buffer at the end.

[earlz]

you could always give them a memory address(and provide functions for lines and such in the runtime lib) and then through paging write to only to video memory if appropriate

[Ready4Dis]

I would do what you plan, most programs will use the higher level functions rather than drawing single pixels. If they must draw single pixels, you should have a function to copy an image from user-memory to kernel-memory so they can use local draw-pixel type functions and access memory directly, then copy this memory to kernel memory in a single call, that's the best way to keep it secure and stuff, and the user can make their own back-buffers or whatever you want to call them. The problem with giving the user access to kernel space memory is you have to give them access to a full page at a time, so for a 16x16 button 4-bytes per pixel (32-bit aligned data), it would be 1k, the user would get access to at least 4k depending on your page sizes, maybe more! That means you either waste 3k or use it for something else and hope the user is smart enough not to over/underwrite (maybe only allocate it to the same program, so if it does screw it up, it only screws up itself and not others, that at least keeps other apps safe from it). Another plus of that is you could make the user app request (lock) the pointer to the buffer each time they wanted to access it and unlock when done, so you could dynamically move the buffers around to keep things more contiguous in memory, if you don't allow direct program access you can do this as well though and is probably the safest bet. Also, it means rather than statically linking a graphics library to each program (or dynamically linking it), all that code is in the video driver itself already and doesn't need to know anything about user-land, simplifies things, and will be plenty fast in most cases.