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.
Related
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
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.
I was looking at Evernote and Producteev for Windows and noticed they used similar GUI toolkits. What tookit(s) are they using? Here's some links., Producteev. (Check the Windows Screenshots) and Evernote.
I am the programmer for the Windows desktop application for Producteev. We didn't use any toolkits for the GUI. All of the UI code was written from scratch based on designs from our in-house artist. We drew a little bit of influence from Evernote (particularly in the toolbar area) to give a familiar look to the application, so that's why there's some similarities.
The application itself is written in C#, and I use GDI+ to make all the drawing calls. There are about a dozen custom-written controls, including buttons (some of which bring down menus), glowing text boxes, list boxes (for tasks). There's also another collection of them to replace for all of the default Windows controls in order to force anti-aliased text rasterizing.
I am new to GUI programming in Windows.
The Windows Resource Monitor (perfmon.exe /res) has four bars (CPU/Disk/Network/Memory) that have gradient backgrounds, as well as charts on the right for displaying recent CPU/Disk/Network/Memory usage.
I am wondering what kind of controls were used in this application. Are they readily available in C++ or in C#?
They are custom controls that are not available for external use, sorry.
You can use the Spy++ window finder tool (Spy++ is included with DevStudio) to find the window class names (and window boundaries).
http://msdn.microsoft.com/en-us/library/aa266028(v=vs.60).aspx
It shows that the overall window is a DirectUIHWND, the graphs are windows but the bars labelled CPU/Disk/Network, etc are not windows at all, the appear to be drawn directly in the resource monitors client area.
The implementation is not public for these controls, but I'm pretty sure they are incorporated using Windowless Controls.
Those bars remind me of Outlook bars. One old implementation is described in Code Project, and that one also has no windows on its own. Everything is painted inside.
Edit: That Code Project article was C# port. For C++ original go to Code Guru.
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)