My application have OpenGL Engine in a WPF hosted Window.
I created half-transparent widget (as Window object) that should display content above OpenGL window. Sometimes when application processing data, widgets backgrounds becomes black (see attached image).
Does anybody know what it is. How can I resolve this problem.
Since Vista Windows supports a new PIXELFORMATDESCRIPTOR flag: PFD_SUPPORT_COMPOSITION. If this flag is set, the OpenGL context creates will integrate into the desktop composition system:
http://msdn.microsoft.com/en-us/library/cc231189(v=prot.10).aspx
It's not guaranteed to work at all. OpenGL windows are not composited with WPF transparency, either below or above. It may work sometimes, but it doesn't have to.
Related
From MSDN article I found out that WinForm controls can be hosted in a WPF application using HwndHost.
Also, from other internet resources, I found that WPF is rendered using DirectX and WinForm is rendered using GDI+.
My question is, what renders a WinForm control when the WinForm control is drawn in a WPF application; DirectX, GDI+, or both?
I have very little experience with both technologies and making baby steps.
Thank you
You are incorrect about requiring a HwndHost to display a Windows Forms control in a WPF Application. The article that you were reading is for Win32 Interoperation, not for Windows Forms. To use a Windows Forms control in a WPF Application, you should use the WindowsFormsHost Class.
As for what will render the Windows Forms control, you need to understand something. WPF uses a totally different graphics system to Windows Forms. From the WPF Graphics Rendering Overview page on MSDN:
One of the keys to understanding the role of the Visual object is to understand the difference between immediate mode and retained mode graphics systems. A standard Win32 application based on GDI or GDI+ uses an immediate mode graphics system. This means that the application is responsible for repainting the portion of the client area that is invalidated, due to an action such as a window being resized, or an object changing its visual appearance.
In contrast, WPF uses a retained mode system. This means application objects that have a visual appearance define a set of serialized drawing data. Once the drawing data is defined, the system is responsible thereafter for responding to all repaint requests for rendering the application objects. Even at run time, you can modify or create application objects, and still rely on the system for responding to paint requests. The power in a retained mode graphics system is that drawing information is always persisted in a serialized state by the application, but rendering responsibility left to the system.
Therefore in general, the WPF Rendering system will render the WindowsFormsHost, although you may find that Windows Forms does actually perform some rendering of its own on the Windows Forms control.
You need to understand WPF and Win32 Interoperation, it show how controls are plotted.
On the other hand Technology Regions Overview explains the relationship between Wind32, WPF and DirectX.
Hope it will make you more clear about this..!!!
I want to create a borderless Window via Windowstyle=None, but still want the default OS DropShadow effect.
I do NOT want to draw the border myself because i do NOT want to set AllowTransparency=True (the application runs on low end systems where this causes very bad performance of the application).
I do also NOT want to use third party Dlls that generate a "Shell" for me.
So what is want is to call the OS native API to draw its default border for me. I tried out this answer here DropShadow for WPF Borderless Window but this didnt work for window 8.
Any suggestions would be helpful.
Thanks
Edit: Using .NET 4.0 and the solution should support Windows 7 and Windows 8
There is no native drop shadow in Windows 8. You can call the API but it won't do anything.
Metro flat design doesn't have drop shadow, unlike the glossy Vista and W7.
AFAIK without AllowsTransparency="True" you won't have that effect.
I'm writing a Video application utilizing D3DImage. Frames are from memory and rendered as textures in native code with DirectX9, finally exposed by D3DImage to the WPF GUI. I have some Overlays on top, created with WPF's painting framework (Text, shapes etc.). Up to this point, it works like a charm.
Now, I would like encode the composited image from my underlying native C++ code. Video is 640x480 BGR, 25 FPS and has to be rendered and encoded in parallel, also on older Hardware with Windows versions down to XP/SP3.
Problem is, I cannot find any documentation describing the composition process between WPF and D3DImage. They 'blend' in some sense, but what is the meaning of this? And is it possible to get a handle to the WPF's part of the drawing or even the composited image in my native C++ code?
p.s: I'm also open to managed solutions, but didn't found much performant up to now.
There is global static method called "CompositionTarget.Rendering". Add an event to that and every time WPF renders that method will be called before WPF presents(the FPS can vary though). So just updated your renderTarget accordingly.
There might be a better way, but i'm not aware of it.
NOTE:: Also for D3DImage on WindowsXP you use a D3D9 device with a lockable renderTarget while on Vista/7 you use a D3D9Ex device with a non-lockable renderTarget. Just a note.
Greetings
I've read WPF utilizes DirectX so I'm wondering if it is possible to create a Game Overlay with WPF. I have tried with Winforms or WPF by itself and the transparent forms or windows always cause problems for streaming software thus I'm wondering is it possible to do the following:
Create a WPF application which shows a Window on the desktop with all the options needed for the overlay. Once all the options is filled in you can press Update and the Overlay is created in the game with all the information on it. The WPF app itself won't be visible on the stream. This means all the viewers will not have any trouble with it when the broadcaster changes settings.
More about the overlay
The overlay will be a scoreboard so it will need a set amount of info. For example:
So to sum up my question(s)
Can I make a WPF application which
dynamically creates a DirectX overlay
ingame?
Since it needs to work in DirectX9,
is this project possible to make by a
single dev (me) which has little to
no exp with DirectX?
If it is possible, where should I
start?
Thanks in advance for all your possible insights and replies!
What you want would be possible using D3DImage. It allows you to host any Direct3D content within WPF and also allows you to have overlay with transparency. Here is a simple example.
From your comment above, it sounds like your really trying to inject your overlay (at least from the user's perspective) into Starcraft II. You would almost have to host a copy of the directx buffer.
Also, besides WPF, you might want to look at XNA.
I have developed a GUI for a random application using WPF. I have a bunch of out of box WPF controls laid on the application window. I haven't customized anything, didn't use bitmaps, etc.
When running my application and zooming using Magnifier application in Windows 7 (Win key + Plus key, the magnified GUI is showing pixels.I am probably wrong, because I can't explain it otherwise, but isn't WPF supposed to provide vector like control rendering?
Thanks for participating in the discussion.
Bonus Reading
Tim Sneath: Magnifier: An Interesting Discovery (archive)
WPF Vector based interface *(screenshot of WPF being vector scaled by Magnifier)
MSDN Blogs: Greg Schechter explains why it longer happens (archive)
Back when Vista first shipped, and when WPF was on version 3.0, zooming with the built-in magnifier would actually do vector-based scaling.
This stopped working when WPF 3.5 service pack 1 shipped. (It worked in 3.5 before sp1.) The reason it worked before then is that the DWM (Desktop Window Manager) - the part of Windows responsible for presenting everything you see on screen - uses MILCORE.DLL to do its rendering. Version 3.0 and 3.5 of WPF also used this same component to render - this meant that all WPF content was native content, so to speak. (In fact, on Windows XP, which doesn't have the DWM, MILCORE.DLL is something that WPF puts on your system for its own benefit. But it's built into Vista and Windows 7.) When WPF was using MILCORE.DLL to render on Vista, any effects applied by the DWM such as scaling would also apply in the way you want to WPF - it really did scale without pixelating.
Unfortunately, this is no longer the case. And the reason is that WPF started adding new rendering features. In 3.5 sp1, the new feature in question was support for custom pixel shaders. To enable that, Microsoft had to release an update to the MIL. (The Media Integration Layer - the bit that does the actual rendering.) However, they weren't really in a position to update MILCORE.DLL, because that's part of Windows - it's how everything you see on screen gets to be on screen. Releasing a new version of MILCORE.DLL effectively means pushing out an update to Windows. The release schedule for Windows is independent of that for .NET, and so the only way the WPF team could reasonably add new features was to ship a new MIL. (In theory they could have done it via Windows Update, but since WPF is now owned by a different division of Microsoft than Windows, that sort of thing doesn't seem to happen in practice.)
As of .NET 3.5 sp1, the MIL is in a different DLL called wpf_gfx_vXXXX.dll where vXXXX is the version number. In .NET 4.0, it's wpf_gfx_v0400.dll.
The upside is that WPF gets to add new rendering features with each new version, without needing Windows itself to be updated. The downside is that WPF's rendering is no longer as tightly integrated with Windows as it was briefly back when Vista shipped. And the upshot is, as you've seen, that magnifying is not as much fun as it used to be.
The magnifier application implements its own zoomed image rendering, so that's why you are seeing pixels. WPF does use vector graphics, but in this situation it's not the WPF application itself that is rendering the zoomed image.
If you use something like Snoop you can see zoomed and scaled WPF vector graphics rendering in action.
I suppose, Windows 7 magnifier takes a snapshot of actual application on-screen UI, and then magnifies it itself (not making a special case for WPF applications). Of course what it can access is just the pixels, not the vector graphics which works behind the scene.
The Windows-7-Magnifier is pixel based, but there is a difference in magnifier mode depending on wether an Aero-theme is active or not.
with Areo theme the zoom is pixelated.
without Areo theme the zoom is smoothed (blurry).
Only with Areo theme other Views (except "Docked") are selectable.