I'm trying to create a borderless window using a WS_EX_LAYERED style window. The objective is to render graphics using DirectX directly to the desktop, using alpha to blend onto the current desktop windows.
Now on my system this technique seems to work perfectly. I can set various alpha levels and achieve different levels of transparency. Unfortunately several users have reported severe performance problems and low frame rate, making this technique unusable.
The code setup is as follows:
Create a layered (WS_EX_LAYERED extended-style) window.
Initialize DirectX using the window HWND.
Create a render target using the CreateRenderTarget DirectX method.
Then during the render loop:
Render graphics to the render target using DirectX calls.
Get the HDC handle to the DirectX render target surface using GetDC method.
Update the window contents using the UpdateLayeredWindow function, specifying the DirectX surface HDC.
My question is: Am I doing something wrong? Is there a way to improve the performance of the window update. I have tried various things, like locking the render target and manually copying the bits to a DIB section to display in the window area, without success.
How big is your window? Note MSDN's documentation at http://msdn.microsoft.com/en-us/library/windows/desktop/ms633556%28v=vs.85%29.aspx says "For best drawing performance by the layered window and any underlying windows, the layered window should be as small as possible."
You may be getting a performance boost if compositing (Aero) is enabled. If Windows is already compositing, it won't have to do as much extra work to draw layered windows.
If you're not seeing any difference in performance depending on compositing, then I am probably completely off base here.
Related
While there are lots of variations of the question, there doesn't seem to be a specific answer to a simple case of wanting to use built-in common controls on a transparent window using Win32. I don't want the controls to be transparent, I just want the border around it to be transparent. I can't believe MS didn't update the .dll's to handle transparency when they added it, but I guess they forgot? Is there a specific method that works. A button can get close with WS_EX_TRANSPARENT, but flaky where it works most of the time but at times part of the border shows up. Edit controls, change depending on when get focus or not.
So the question is simply:
Is there a way to make common controls on transparent window so there is no white border around them?
If not, is there a good replacement library that does it via owner draw?
If some, which ones and what is the method?
Seems silly to reinvent the wheel just because of the area around the control.
TIA!!
If I am not mistaken, you can take the following steps to achieve this effect.
1.Create a GDI+ Bitmap object with the PixelFormat32bppPARGB pixel format.
2.Create a Graphics object to draw in this Bitmap object.
3.Do all your drawing into this object using GDI+.
4.Destroy the Graphics object created in step 2.
5.Call the GetHBITMAP method on the Bitmap object to get a Windows HBITMAP.
6.Destroy the Bitmap object.
7.Create a memory DC using CreateCompatibleDC and select the HBITMAP from step 5 into it.
8.Call UpdateLayeredWindow using the memory DC as a source.
9.Select previous bitmap and delete the memory DC.
10.Destroy the HBITMAP created in step 5.
This method should allow you to control the alpha channel of everything that is drawn: transparent for the background, opaque for the button.
A similar discussion: Transparent window containing opaque text and buttons
Is it possible to use the trick with overriding wm_nccalcsize to draw over entire window area with opengl?
I need to keep all aero features for windows (win 7 in this case), so i use (WS_POPUP | WS_SYSMENU | WS_MAXIMIZEBOX | WS_MINIMIZEBOX | WS_THICKFRAME) styles
It works fine for maximized mode, I can leave the border outside the screen by adjusting the Lparam.
But a regular window still has 8px borders around it, even though they are supposedly part of client rect (which I checked with GetClientRect()
Image: dark-grey border is visible
And this is all done before I init opengl context. So I dont know what's happening. Or if this even possible. Am I supposed to just create borderless and re-implement all aero features? (no way I'm doing that)
upd 2:
If I draw a rect with GDI right before I init Opengl context this is what i get:
a nice (0,0,200,200) rect, starting in the nonclient area
So it is opengl context issue. I saw in msdn docs, that opengl draws only in client area. And it still does that, ignoring that I extended the client rect to whole window. siiiigh.
The usual way to combine Aero with OpenGL is to set the window client area using the DWM API to zero. This allows you to draw to the whole window (including titlebar) using OpenGL. I have this test program to tinker with it as part of my wglarb wrapper:
https://github.com/datenwolf/wglarb/blob/master/test/layered.c
You may also be interested in my dwm_load wrapper, which allows to you call DWM functions without rigidly linking your program against DWM (which makes it incompatible with older Windows versions; you wouldn't believe how often I still get "must run on WinXP" as a feature requirement) https://github.com/datenwolf/dwm_load
We need to overlay a target window with a custom shape and tracks the position of the target window such that the overlay drawing always appears above it. Also, the overlay drawing should appear in screenshots taken using BitBlt or PrintClient by screen-capturing tools like Camtasia, Debut, etc. Also, moving the target window around should not leave traces of the drawing at earlier location. The target window is not made using our code.
So far we've tried several ways but each method has its problems:
1) Layered Window:
Using a layered window as the child/owned window of the target window is the easiest thing and it works. But the problem is on Windows 7 and XP, layered windows do not appear in a BitBlt done without the CAPTUREBLT flag and the screen-capturing tools may call BitBlt without the flag, thereby skipping our window from the capture.
2) Region Window:
The crude approach to support all Windows versions then is to use a region window using SetWindowRgn and make the target window its owner. However, region windows are generally very slow in rendering complex shapes and also impact the performance of other windows, sometimes to the point of freezing the application. Region window also leaves traces on dragging the application window.
3) Subclassing and Drawing on HDC:
Another approach is to sub-class the target window and draw the shape on its HDC on the OnPaint() event inside the window procedure hook. The shape can be drawn on the desktop window instead too. The problem is that applications may draw without a paint event, like when some text is selected using the cursor, and such drawing may erase a part of the custom drawing. Tracking all possible paint events is not a good way to do this.
4) Drawing continuously in a timer:
The last resort is to draw the custom shape on the target window in a timer continuously so the drawing is always above the target, even on text selection. But this may show a bit of flicker when the text is selected. Not to mention, it is very performance heavy to draw constantly.
Question
What is the best way to achieve an overlay drawing which works on all Windows versions (since XP) at the same time appearing in screen-captures. We've exhausted all approaches. Is there some method I'm missing? Can the above mentioned ways be used with some improvement? Is DirectX an option? I'm looking for methods with fast rendering capacity to achieve this. Appreciate any help!
I think the best solution to draw an overlay window, is to use a double-buffered technique GDI, just like in this example:
Overlay Drawing in CScrollView
I have myself the same task, and the only solution was that one. Hope it help you.
I'm searching for how to render window to 3D windows Texture on D3D
for example, the windows aero-glass's preview.
a window or part of window that has a windows handler is rendered to a d3d device(i guess aero glass is maked by d3d).
my project is a 3D interective media. it is an AR project using HMD and Hand Recognizing.(Like a 3d touch interaction )My part is 3D Rendering. The WPF can do this. But i don't find the way how to do it with D3D.
Who knows the way or it is impossible on D3D? if you know, please notice me a KEYWORD that using to Google.
thanks to reading and your attention. i'm not native english user and i'm sorry that if you feel my english seems ugly.
I may suggest using dynamic textures. You first create a texture of the desired size and format. Then you get its surface, obtain HDC and pass it to a window you want be drawn. Showing a texture thru d3d device shouldn't be a problem.
I'm trying to get the media player glass effect for an application, but I'm facing roadblocks all around. Is it me, or is it the API?
I started by calling:
MARGINS margins = { -1, -1, -1, -1 };
HRESULT result = ::DwmExtendFrameIntoClientArea(m_hWnd, &margins);
And erasing the background to black on:
OnEraseBkgnd
Everything was fine until I added an edit box. With EditBox, places where black text appears are replaced with glass. The problem is blown out of proportion with more advanced controls like ComboBoxEx and that like. Those start to look like mess.
The bright side with this approach is that the alpha blended images look alright. And are gradually blended into the glass.
The solution for edit boxes seems to be using WS_EX_LAYERED with LWA_COLORKEY and using some awful color for glass masking, and erasing the background to that color. Unfortunately this breaks other things. The alpha blending on icons looks super ugly with shadows blended to radioactive green, and the glass itself becomes click-throughable, even though I don't have a WS_EX_TRANSPARENT style on the window.
The third suggestion is sort of custom composition with GDI+, but that seems to be a bad approach, since GDI+ is a software fallback, and I can't find a way how to render EditBox or ComboBoxEx to an image that I could use for composition later.
Am I missing something?
The sources at SO also seem to face the same problems:
link1
link2
Kenny Kerr wrote an excellent article on displaying controls on glass, using edit controls as an example:
http://weblogs.asp.net/kennykerr/archive/2007/01/23/controls-and-the-desktop-window-manager.aspx
The simple answer is, you cannot do this.
All the standard controls render themselves with normal GDI calls. Normal GDI calls are alpha unaware and mostly set the alpha channel to zero.
The more complicated answer is, you can: There are some samples on the net where standard controls are mixed with aero glass. They fall into two basic categories:
WinForms (.NET) samples. WinForms don't actually use the native controls - the WinForms controls are all rewritten versions that, amongst other features, blit using alpha aware routines. This example is depressingly simple and makes me realize how much Microsoft hate native developers.
Subclassed samples: The only way to get the regular/native controls to paint on aero glass is to sublclass the controls, catch WM_PAINT messages to create a DIBBitmap, call WM_PRINT to render the controls content onto it. Use the DWM functions to repair the alpha channel data. Paint the resulting alpha'd bitap yourself using AlphaBlend.
This article on CodeProject contains a reference implementation that subclasses most of the standard controls rather well.
Try changing your text/foreground color on controls like the edit box to something "almost black" (like #010101). Then you should be able to skip the other rendering issues except alpha transparency for images/icons.
Edit: Drawing other stuff - might be some weird approaches to handle compatibility, but then again classic apps aren't glass themed by default ... don't know. Just try to avoid drawing stuff yourself, if possible.