I'm forwarding this here as requested by Henry Nestler.
I also changed the subject as it's not SDL related but Win32 API.
I also want to explain that the BitBlt() function is not the trick here.
The real trick is creating a DIB section (a bitmap) with their bits
(data) pointed to the shared memory where the FB is. The FB linux driver
must use the same type of bitmap codification (it's pretty standard,
anyway - just assure rows are dword padded).
After this, we create a working device context that will serve as a
back-buffer and select the DIB (Device Independent Bitmap) into it.
Then we only need to update the window on normal WM_PAINT messages,
using BitBlt() to that end.
What we gain with this method is that a simple minimize/maximize will
refresh the window with the latest FB changes, no need for copying bits
from memory to accomplish this.
For those interested, the relevant code is all in the MainWindow.pp file.
Henry Nestler wrote:
please post THIS mail to the list for all other developers!!!
You have very good describe the "transparent background idea". I have
read all other mails, but not understand the nice idea. After reading
this mail, I'm know what you means. Very nice!
Please forgett SDL. you should also rename the subject. It's confuse for
I'm realy happy about your demonstration ("prototype" ;-) )!
PS: Sorry for some mistaken in my english, my german is better, but
nobody understand this.
Nuno Lucas wrote:
> Hi Henry.
> Henry Nestler, dando pulos de alegria, escreveu :
>>> After looking at the CoLinux FB demo (prototype?)
>> It was my testprogramm for handling SDL, shared memory in mingw
compiled environment, and also a performance check for this all.
> Ok, I was just in doubt of what would be the better english word to
>>> I tried to make it
>>> work with some of the ideas I had, but SDL doesn't seem to accept
transparent windows of any form (it seems the fault is that DirectX
doesn't cooperate very well with the basic GDI).
>> SDL should handle transparent. SDL can draw a object over a other
object. But SDL use a unused color to handle this.
>> What do you means? Transparent objects in a Window. Or a transparent
window on desktop (in comparsion the desktop icons do this)?
> You should have run the program by now and you should have seen the
transparent boxes demo (I was unable to do it with SDL). So, yes, it is
the transparent windows concept (that, unlike X, Windows supports
natively since Win2k).
> The idea is having X windows appear in the desktop without the
background, similar to the multi-homed Cygwin X server. The downside is
that when one X windows is on top, all other X windows will be on top
too, but I think we can live with that.
>> Thanks. I would check this in next night.
>> Sorry, I can't post to gmane.linux.colinux.devel.
> One thing I have to add is that my intention is not to replace your
demo, but having another performance comparison program. From my search
on the topic I found out only two ways of fast blitting into a "Windows
window" natively: creating a back buffer with a DIB (the way shown here)
and DirectX (basically the same, but with a DirectX surface).
> From what I have read, DirectX doesn't cooperate with the windows
GDI system very well in respect to transparency, so I decided to go for
the DIB section method and test the performance with transparency.
> On my P4@..., seems ok, but I also have a (low) medium-range
graphics card (an ATI Radeon 9600SE, with 128MB), so I'm not sure of the
> Another thing I would like you to confirm is that it seems the rect
queue doesn't seem to add significant performance (in this simple demo,
at least). The random pixel demo invalidates all screen for every pixel
and when simultaneously running with the random boxes demo, doesn't seem
to interfere much (but this can be from my relatively modern video card).
> This also can give some clues about the "dirty bit" MMU optimization.
If the rect queues don't add much to performance, then I don't see an
active polling for pixel line changes and more processing for address
reverse translation to x,y coordinates as adding some substantial improving.
> Maybe what we need is also to work on a way to measure the
performance, so we can make unbiased comparisons on the methods.