What is the best way to access the rendering area of every single window in Microsoft Windows, so I can render them myself in 3D? I know the Desktop Window Manager (dwm) gives every window a rendertarget and renders them alltogether on the screen.
There are tons of 3D window managers out there, but finding some code or other information is hard for me, so I'm asking you.
I would like to do it in OpenGL, but I can imagine it's just possible in DirectX, but that's fine too.
Thanks in advance!
You have to use the operaring system / graphics system specific API dedicated for that task. OpenGL is operating and graphics system agnostic and has no notion of "windows".
In Windows the API you must use is the DWM API. For Windows versions predating the DWM API (XP and earlier) some "dirty" hacks have to be employed to get the contents of the windows (essentially hooking the WM_PAINT and WM_ERASEBACKGROUND messages, and the BeginPaint and EndPaint functions of the GDI to copy the windows' contents into a DIBSECTION that can be used for updating a texture).
In X11 the API to use is XComposite + the GLX_ARB_texture_from_pixmap extension
Related
Under Windows, when the DWM composition is active, there's a somehow "special path" for fullscreened OpenGL applications that prevents all other subwindows (popups, menus, tooltips) to be correctly layered on top of the fullscreened OpenGL window.
While this is useful for games and such, it's totally a pain for other fullscreen OpenGL applications (CAD, 3d editors, etc.). This problem is causing endless troubles for Qt users, see here, here, or here.
Is there a way to tell Windows not to enable the special path for a given application / fullscreen window? Either in the manifest, or via DWM APIs, I don't care.
Yes, this can be done by tricking Windows into thinking that the Window should be composited with transparency. For this you call DwmEnableBlurBehindWindow on the window. In case of a fullscreen WS_POPUP window this makes the window fully transparent (instead of the glass effect) and you can use the window's alpha channel to control the opacity; for a regular window with a title area and border you get the glassy effect then.
Now if you configure the pixelformat without an alpha channel or set the alpha channel to all 1 (full opacity) the compositor still has to assume some transparency may be present and goes through full composition.
Small update
Although WinXP and Win2k are beyond their EOL, it may be undesireable to hardlink the dwmapi.dll to the executable, e.g. if you have to support legacy systems with your software for some reason. For that I wrote a small wrapper library dwm_load that dynamically loads the dwmapi.dll if available or falls back to failsafe implementation of the DWM functions.
I've heard about various methods of rendering to a Window, but these all involve using some thing such as GDI+, DirectX, OpenGL, or something else.
How do these libraries work, and how do they get pixels into a Window? Just out of curiosity, how hard is it to raw access a Window's image data?
Thanks.
That's a pretty broad question.
The various Windows subsystems that draw images interface with the video drivers. Or use so combination of working with GDI+ and interfacing with the video drivers. How the drivers work is going to depend on the video card manufacturer.
I don't know what you mean by "raw access a Window's image data." You can capture a window's image into a bitmap, massage it, and write it back to the window's DC. But getting to the actual bits that Windows uses to render the bitmap would require digging into undocumented data structures. You'd have to know how to follow a window handle down to the low-level data structures that are maintained inside the GDI subsystem.
This is basically a scoping question, where would I look for the facility to render window contents to 3d surfaces and manipulate them? I mean can I have a program like a shell that composites live windows in 3d like the Vista DWM's 3d Task Switcher and can translate UI interactions back into 2d interactions for each window?
I've seen mention of DWM extensions here and there on the web but can't find any resources as to how that would work. Also there are guides to implementing DWM Thumbnails by relating two windows' HWNDs but that doesn't allow me to do arbitrary transforms on the window and is display only (you can't click on stuff in the thumbnail.)
Any ideas?
There is no interface for manipulating the DWM's 3D visuals. They are internal to the DWM.
Through experience I have found that the native windows forms/components don’t like to be changed. I know using Delphi or Visual Studio you are given native windows components to populate a form or window with and then you attach code on events that these components may do (onClick for example).
However, how do all of these programs like Word or google’s Chrome browser alter the standard windows’ window? I thought it was somehow protected?
Chrome seems to have tabs actually on the window’s frame?
I know you can also get toolkits like Swing and QT that have their own controls/components to populate a form. How do these work? (How does the operating system/computer know what a non-native button should act like? For example; Chrome's back and forward buttons, they're not native components?).
I can understand how OpenGL/DirectX window would work because you’re telling the computer exactly what to draw with polygons/quads.
I hope this question is clear!
Windows does not protect GUI elements. Windows and controls can be subclassed to handle various drawing operations in a custom way. For example, windows may override and reimplement the handling of the WM_NCPAINT message to draw a custom titlebar and frame:
http://msdn.microsoft.com/en-us/library/dd145212(VS.85).aspx
Some Windows controls have an "owner-draw" mode. If you use this, you get to draw the control (or at least vital parts of the control), while Windows takes care of responding to user input in the standard way.
Swing ant QT draw their own widgets at a low level using basic primitives, but they also have theme engines which can mimic the native controls.
Qt moved to native controls a while back. As for how swing does it, it gets a basic window from the OS. Then much like Opengl\Directx it does all of the drawing with in that window. As for where to position things that is what the layout managers do. Each manager has a layout style horizontal, vertical, grid, components it has to draw and a section of window it is expected to fill. From there it does some pretty easy math to allocate its space to its controls.
There's no magic: non native controls are simply drawn on a blank window. Or, instead of being drawn they may be represented as one of several bitmaps based on state (ie: a button may be represented as a .png for the normal state, another .png for the pressed state, etc)
It seems Windows is unable to display different background images on different monitors on a multi-monitor system out of the box. But I noticed there are quite a few commercial applications available which provide this feature.
Which APIs can be (mis-)used to provide this functionality? If there's no special API for this feature, can it be done by hooking into another Win32 API function? If so, which one?
You could also try to programaticaly create an image the size of the virtual desktop joining several images making the divide fall where each monitor ends and then set that image as a wallpaper.
Simple and low tech.
Wallpaper replacement applications on Windows don't hook into the Windows API, they make a window the size of the desktop and render an image on it. There's APIs in Win32 to make such a window unclickable and living below everything else, and sized correctly for the desktop.