moving window like other os does

[digo_rp]

I´m trying to move window like others os does " windows, linux "

I set up AGP data rate to 4x and 8x

I´m using memcpy_mmx in my function getimage/putimage

but its slow, anyone has some help ?

[Osbios]

Do you know Blitting? I think, even VESA supports Blitting. Its a fast copy of memory blocks (e.g. images) from video ram to video ram.

[Combuster]

write-combining would help too...

[digo_rp]

does anyone could give some start ?
I don´t have how to look up at google,
some inline, nasm c# statement please

[Dex]

Go here : http://alexfru.narod.ru/
And get "My Windows Manager Demo"
Its abit slow, i think there maybe a faster mirror ?

[Brynet-Inc]

Go here : http://alexfru.narod.ru/
And get "My Windows Manager Demo"
Its abit slow, i think there maybe a faster mirror ?

Hey sure thing ..
I downloaded it awhile ago so I'll mirror it at rapidshare.com:

Code: Select all

http://rapidshare.com/files/19577291/WinMngrDemo.zip.html

It's only 330K, but Alex's host is painfully slow..

[maddog39]

Another really cheapo solution would to try and use inline functions to help boost performance, but probably wouldnt give too much of a boost/difference. I personally know almost nothing about VGA so far, but would like to learn it.

[Combuster]

Another really cheapo solution would to try and use inline functions to help boost performance, but probably wouldnt give too much of a boost/difference. I personally know almost nothing about VGA so far, but would like to learn it.

If you can assume a vga, then you might want to try the old trick of using the latches for video-to-video blits.

Also, i've been peeking around the intel and amd manuals, and reading from an uncached area causes a flush of the write buffers in WC/WT/WP areas: i.e. if you alternate reads and writes you'd get horrible performance: a read forces the write buffers out, before the read is executed, (which is delayed because of that) then the next write loads an write buffer, which is then emitted on the next read. Consequence is: you do not get burst transactions, which will saturate the PCI bus and dramatically slow down processes.
The trick is to align addresses and group as much loads and stores together as you can to get maximum throughput. (You should read the AMD optimization guides for more in-depth info) Alignment is also something worth watching out for...

[Solar]

Hmmm... isn't that what "2D acceleration" is about, i.e. shouldn't this be covered by the graphics driver / GPU instead of the CPU? (Haven't delved into graphics myself yet so I don't know for sure...)

[Combuster]

Hmmm... isn't that what "2D acceleration" is about

Welcome to the world of proprietary hardware
Besides, the thread starter never assumed anything other than an AGP framebuffer device. Giving hardware specific info would only help with a limited set of devices.

[Solar]

Hmmm... isn't that what "2D acceleration" is about

Welcome to the world of proprietary hardware

I know... but unfortunately it's reality, isn't it? A generic driver (framebuffer) will always be slow when compared to how Windows / Linux do it, because they both use device-specific drivers.

[Dex]

As a side note, he should be thinking in terms of writing the most optimised wire framed box draw function, the size of the window. As it is quicker to move this around than the whole window, once the mouse button is released or the mouse+button is stopped moving, the win can be draw in the new X Y (with checks for half off screen etc).

[Candy]

Hmmm... isn't that what "2D acceleration" is about

Welcome to the world of proprietary hardware

I know... but unfortunately it's reality, isn't it? A generic driver (framebuffer) will always be slow when compared to how Windows / Linux do it, because they both use device-specific drivers.

Well.... if you install the ati drivers without shmem compiled in, they're slower than a framebuffer. That's a bit offtopic though.