View Full Version : Transparent Window Demo

06-22-2004, 10:35 AM
It seems like i've seen posts asking about this kind of thing for a long time, but with no resolutions. So I decided to try my hand at it.

It works nicely on the cards I have at hand. This is a Windoze 2000/XP only demo.

Sorry, there is no source with it yet. The source is still unclean.

Download (http://www.coreytabaka.com/index.php?r_s=541&r_p=543&flog_id=4)

Let me know what you think ;)



06-22-2004, 01:00 PM
Woah ! Superb !

Your splash screen is a bit misleading, first I though 'hey, is that GL stuff ?' :)

Maybe I ask for too much, but is there any chance to actually blend the spheres above the windows desktop , like your 'about' screen ? The 'transparent' mode only make the mouse click trought the spheres.

Win2000, Gefore3ti200.

Very interesting, I would really like to see the sources, even if it is ugly as hell.

Congratulations !

06-22-2004, 01:48 PM
Excellent work dude!!! How did you make it?


06-22-2004, 02:05 PM
Originally posted by yooyo:
Excellent work dude!!! How did you make it?

yooyoMy guess: Render to an RGBA pbuffer, readback scene, blit with gdi and set colorkey/blend depending on the alpha channel or background color of the scene.

The splash screen is intriguing, though...

06-22-2004, 11:42 PM
this thing really rocks!


06-23-2004, 02:28 AM
Originally posted by evanGLizr:

Originally posted by yooyo:
Excellent work dude!!! How did you make it?

yooyoMy guess: Render to an RGBA pbuffer, readback scene, blit with gdi and set colorkey/blend depending on the alpha channel or background color of the scene.Not sure : you can even click through this window holes on the windows under it!

06-23-2004, 03:41 AM
This rocks. I'm really interrested in seeing the source. :cool:

06-23-2004, 06:49 AM
Very nicly done.

06-23-2004, 07:27 AM
Originally posted by tfpsly:

Originally posted by evanGLizr:

Originally posted by yooyo:
Excellent work dude!!! How did you make it?

yooyoMy guess: Render to an RGBA pbuffer, readback scene, blit with gdi and set colorkey/blend depending on the alpha channel or background color of the scene.Not sure : you can even click through this window holes on the windows under it!That's part of the normal layered window (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/layerwin.asp) hit test (http://msdn.microsoft.com/library/en-us/dnwui/html/layerwin.asp?frame=true#layerwin_topic2b) behaviour:

Hit testing of a layered window is based on the shape and transparency of the window. This means that the areas of the window that are color-keyed or whose alpha value is zero will let the mouse messages through.
If the layered window has the WS_EX_TRANSPARENT extended window style, the shape of the layered window will be ignored and the mouse events will be passed to the other windows underneath the layered window.
I'm quite sure everything is just an RGBA pbuffer & a GDI blit, using colorkeying or blending, depending on whether you want fully transparent/per window translucency or per pixel translucent windows:

To use UpdateLayeredWindow, the visual bits for a layered window have to be rendered into a compatible bitmap. Then, via a compatible GDI Device Context, the bitmap is provided to the UpdateLayeredWindow API, along with the desired color-key and alpha-blend information. The bitmap can also contain per-pixel alpha information.

06-23-2004, 10:28 AM
Probably right about about readback and blitting cause it runs slow for something really simple.
For sure it would work this way.

06-23-2004, 04:58 PM
Great job, never seen anything like it before. I would love to see the source for it. I noticed i could click on a window behind the program even in the smalled hole inbetween the spheres.. does this mean it uses the windows API for this type of stuff? (I know VB does something like this, not sure about C++/C)

Well, nice work regardless
Hope to see the source soon ;)

06-23-2004, 10:53 PM
Originally posted by zix99:
I know VB does something like this, not sure about C++/C)Pfff... If a vb interpreter written in C/C++ can do it, why a C/C++ program would not be able to do it ? :rolleyes:

06-24-2004, 06:38 AM
Thanks for all the responses. :)

My apologies on not having the source ready. I don't have a lot of free time, even to work on demos like this. Perhaps I'll be employed doing work that better corresponds to interesting things like this in the future.

Anyway, evanGLizr is almost dead on. I do use UpdateLayeredWindow and glReadPixels to achieve this effect. AFAIK this is the only way to do this cleanly, since Windows has issues with mixing layered windows and OpenGL. Perhaps Longhorn will bring a better solution. However, this is not really the clever part of this demo. I didn't create any messy offscreen windows or use the desktop window to get an OGL context (since that doesn't work on the NV cards I have).

I'll try to get the source up soon.

Thanks again for the interest,


07-04-2004, 06:00 AM
Man this really is sweet. When can we see the code? :D

07-06-2004, 06:13 AM
Very cute, very nice. It would be fun to have the source code to make my own little silly creations, like intermitent shooting stars when there's no keyboard or mouse activity...

I would like to report that I can't drag the cube to my second monitor. That's not really a surprise, but just an FYI. They're both being driven from the same card, an ATI FireGL X1 AGP Pro.

07-16-2004, 04:45 AM
This looks like a resume' to me. I just like to leave it running, it's pretty cool I think...
Somebody get that man a job :p

anyway, to be useful in my post:
I have noticed the issue with the second screen.
I can get it to work on both screens (ATI) if I load the program, then enable the second screen. I do not know why this is, but it just happens to work that way on my system.

07-19-2004, 06:09 AM
Just thought I'd comment on an earlier post.

@V-man: I don't think the slowdown you are experiencing is due to the readback and blitting. This demo uses a 400 x 400 RGBA pbuffer. Doing the math you get 640K per frame. I cap the demo at 60 fps, so the required bandwidth is only 38.4M/s, disregarding state change overhead. This is less than 1/4 the AGP 1x theoretical bandwith.

I believe the slowdown in your case is due to fill rate. I noticed this on my GF FX 5200 (notoriously fill limited). It's easy to miss the fill requirements because the subject is so simple; it just renders some rotating spheres. However, I naively render the spheres without any depth sorting and I don't render ambience and z first, so I don't take advantage of early depth rejection. I also calculate all the lighting in the fragment shader, so performance takes a hit there too (on top of using ARB FP1).

I estimate that in the worst case the demo shades around 210K fragments per frame using this metric:

Estimated coverage of the closest plane of spheres when parallel to the view plane: 50% = 400 x 400 x 0.5 = 80,000 fragments.

Estimated coverage of the middle plane when aligned parallel: front coverage - 10K = 70,000 fragments.

Estimated coverage of the farthest plane when aligned parallel: middle plane - 10K = 60,000 fragments.

Leading to a rough estimate of total coverage in the worst case: 80K + 70K + 60K = 210K fragments per frame = 12.6M fragments/s.

I think that the fp shader and fill combination is much more substancial than the meger bandwidth requirements of the blitting, even given the coarseness of my estimation. Also, the demo renders smooth when using only fixed function, even though I bump up the LOD significantly. Perhaps I should add "Use Fixed Function" as an option when fragment hardware is detected.

In the little time I've had to clean up the code I fixed the problem on ATI cards where the window doesn't render on secondary displays. A two character fix, thankfully.

So hopefully I'll have some nice source for everyone some day soon. I appreciate everyone's comments thus far and any feedback you provide me.



07-19-2004, 08:25 AM
Crashed instantly, no window appeared :(
5200 & Windows 2000

lost hope
07-20-2004, 01:13 PM
yes, it crashes instantly on my computer as well:
vid card: FX 5900
os: XP
driver version: 56.72
running dual monitors

07-20-2004, 02:24 PM
It works smoothly here : Radeon 8500/Win2000, with no fancy shading though.

What bugs me is the size of the executable (744KB). Ok there must be embedded resources (ttf, jpg or whatever), but still... Plus you must add two dlls : 856KB (cg.dll) +188KB (cggl.dll)

Anyway, it definitely looks good. I hope you'll find a job soon.

07-21-2004, 09:25 AM
The crashes on NV cards are from a line of code I forgot to remove while fixing the earlier ATI problem. This has been fixed. My apologies for any frustration this has caused.

@kehziah: Yes, the executable was a little large. I made some changes and reduced it to around 268K. As for the dlls, I haven't figured out how to statically link to the Cg runtime. I know it was possible with the beta version of the Cg libraries, but I haven't had much time to learn how to do it now. Does any one else know?

Also, the demo uses ARB FP1 and VP1 for per-pixel lighting. IIRC the 8500 supports only the ATI fragment shader extension. I may add support for PPL on a broader range of hardware in the future, but using ARB FP/VP was a time vs. necessity choice--this is a demonstration of transparent windows, after all.

I've only had a few complaints since I broke the demo for NV hardware. The implications of that are interesting.

Thanks again for the responses,


07-22-2004, 02:28 PM
I tried running a normal OpenGL demo along with your demo, and
everything slowed down horribly to a snail's pace. And the windows area
where the two demos intersected was not drawn.

Found some info on a Google search. It seems using layered windows
and OpenGL/DirectX is not recommended by Microsoft:

From: Greg Binkerd [MS] (GregB@online.microsoft.com)
Subject: RE: WS_EX_LAYERED and OpenGL together?
View: Complete Thread (3 articles)
Original Format
Newsgroups: microsoft.public.win32.programmer.gdi
Date: 2002-06-05 10:18:55 PST

Hi, Craig.

Unfortunately, OpenGL (and DirectX) can not be used in a layered window.
The hardware performs all rendering and will not incorporate the
semitransparency effect displayed by a layered window. In fact, if you
create a layered window and you move it over an OpenGL application or
windowed DirectX application, you will see "flashing" of the layered
window, since the hardware will draw the 3D primitives directly on the
primary surface, drawing over the layered window and the layered window
will immediately redraw itself in a semitransparent state. Note, this will
only occur with hardware accelerated OpenGL and DirectX applications.

Microsoft Developer Support

07-22-2004, 10:00 PM
I know it may be slow, but couldn't this
problem be solved by rendering into a texture,
then using glGetTexImage to get the result of
the rendering and then blit this result on
the surface of the window as a GDI bitmap ?

07-27-2004, 04:28 AM
@gator: I've noticed this slowdown too. This appears to be related to using pbuffers, but the frequency of updates to the layered window probably contributes. Try any of the ATI or nVidia pbuffer demos along with the demo you mentioned and you will see a similar, although possibly less pronounced, effect. I've noticed that most consumer level cards are not very good with multiple OpenGL contexts, especially ones using extended functionality. Hopefully this will change in the near future.

It seems using layered windows
and OpenGL/DirectX is not recommended by MicrosoftYes, in fact trying to create a context on a layered window will bring your system down in XP. However, this demo does not mix the two, it simply uses OpenGL to generate the image information for the layered window--the layered window does not have an associated context. As for the flickering, that is the situation with all layered windows. Try animating another layered window app, such as WMP, over an OpenGL app and you will see similar effects.

02-08-2011, 10:51 AM
There's nothing like reviving an old thread! @Dude, we are still waiting for the Cube's code.

Meanwhile, you guys can check this thread on StackOverflow:


Even though it's probably not the technique used by the Cube demo, it has a working source code that achieves the same effect.

Alfonse Reinheart
02-08-2011, 11:55 AM
This thread is 7 years old. The stuff it's talking about is oudated, and the people who posted here haven't posted for years.

You're talking to nobody.