I have been looking at making my own window frame in WPF, similar to Visual Studio. I have read that setting AllowsTransparency = true would force WPF to render in software-mode. This example is the source of my confusion (emphasis mine), which states:
Complete customization of WPF window can be done only when AllowsTransparency is set to "True", which causes that the window is software rendered which might be not as fast GPU rendering.
However, I've read elsewhere that with window layering you can have hardware-acceleration and this is what WPF does. I also find it hard to imagine that Visual Studio 2013 -with its custom frame and transparent border blur- would be software-rendered.
Is there a definitive answer to the question (assuming Windows 7 onwards), Is WPF Hardware-accelerated when Window AllowsTransparency is true?
It seems that transparent windows (AllowsTransparency = true) are hardware accelerated for Windows Vista and upper: HW Acceleration of Layered Windows
There is also an hotfix to make it work under windows XP as well: http://support.microsoft.com/kb/937106/en-us
I'll add my two cents too.
Yes, it's true. From Vista onwards, we have hardware acceleration for layered windows, and there seems to be a hotfix for XP aswell.
This is where the good news stop.
Don't try and use AllowsTransparency - trust me, there's just so much that can and WILL go wrong, despite it being hardware accelerated. Ofcourse, think about your use case: if it's simple hobby project, not an enterprise level application, then, go ahead.
Some of the problems I've personally experienced:
major performance, believe or not, "performance problems with AllowsTransparency" is not made up concept. Animations suck.
Integration with other technologies. I remember integrating DirectShow solution to a window that had AllowsTransparency true. It did not work, as DirectShow does not support rendering to a window that is layered.
This guy seems to be even talking that software rendering is sometimes faster than hardware, for layered windows, which I kind of agree. My experience has also shown that "hardware acceleration" is nothing spectacular on WPF.
I remember switching to software rendering, and saw no performance loss. In fact, I suggest to disable hardware rendering because it's complex, and it causes visual bugs, if you're targeting wide area of different configurations (XP, XP64, Vista, Win7, different video cards) - famous black spots.
By the way, VS2010 SP1 disables hardware rendering for visual studio on XP, even if it supports it. Why? "A significant number of crash reports stemming from the hardware acceleration"
That said, Visual Studio2013 does not use AllowsTransparency - correct me if I am wrong, but Snoop revealed that the main window has AllowsTransparency set false.
How can you have a custom chrome window, that is not layered & PERFORMS well? This is quite complex subject, but you can get started if you google for "WPF Custom Chrome library". I suspect VS does something similiar.
Related
I had been developing WinForm apps in a long time. I just recently bought a Surface Pro 3 to serve as my new development PC. Unfortunately I noticed an issue with the GUI editor. The some of the sizes of the controls don't match with what appears in the GUI editor and with what appears in the actual running application. For example, the sizes of my panels don't follow what it looks like in the GUI editor when I run the app. They usually increase in dimension. I am not really sure if it is a VS issue or maybe it has something to do specifically with using Surface Pro 3?
To demonstrate what I mean consider the following screenshots. Notice the difference in the size of the Menu Bar in the GUI Editor and in the actual application.
If you want to prevent your app from changing size, you can make it independent of DPI settings. Your app will be pixel perfect but on high resolution screens may be too small.
All you have to do is to change AutoScaleMode property of the main form and set it as None.
I know this is an old thread but I was experiencing the same issue... I found a workaround which you may find useful...
After trying a few things it became obvious to me that windows 10 was attempting some "intelligent" resizing of forms under Windows 10 on the surface pro (I am using a surface pro 4)... I am not sure if it is a win10, high-res or surface pro issue.... whatever it is it was messing up my control sizing, placement, anchors and resolution.
I found that if I made a note of the intended size of my form in the designer and then manually set this in code at the end of my Form_Load event, it would override this unintended behaviour and I ended up with my originally intended form size and control placement, I also needed to re-center the form in the parent/screen to get the desired result (of course only if that is the intended start-up position for your form)
The code that worked for me (at the end of the Form_Load event) is...
this.height = 800;
this.width = 600;
this.CenterToScreen();
I hope this helps somebody, I was pulling my hair out for a while!
It has been a while since I posted this question and I kinda forgot about it. I thought I should share my recent findings for those who will find themselves in this same predicament.
I learned that the discrepancy between the GUI editor and the actual running app was because of the super high DPI scaling of my Surface Pro 3. Visual Studio was automatically running at 216 DPI (225% display scaling) compared to the usual 96 DPI (100% display scaling) of common computers. My workaround back then was to simply adjust my controls accordingly thru trial and error and to anchor most of them between the GUI editor and the running app. Eventually, it became less of an issue since I moved on to a normal desktop with a normal screen for my regular software development. Moving forward, I recently stumbled upon a Microsoft documentation regarding Automatic Scaling in Windows Forms. It explains the issues with multiple DPI scaling for Windows Forms. It also includes this bit about the DPI scaling issue of Visual Studio:
With the extreme differences in display DPIs, especially in modern 2-in-1 devices, this can still happen with the most current versions of the .NET Framework and Visual Studio. To address this in a team using different DPI displays, make sure Visual Studio always starts in a non-DPI-aware mode, so the Windows Forms designer always bases the layout calculation on 96 DPI.
The solution they suggested is to add or import a registry value that disables Visual Studio's High DPI awareness:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\devenv.exe]
"dpiAwareness"=dword:00000000
I tried it and it definitely works. I hope it helps you too. :)
We have a Wpf app hosted by a single Citrix Server used by up to 8 remote users. The WPF app is usually used with a high resolution and multiple monitors at the same time so we want to make sure the GPU is used for rendering instead of CPU.
We are using grids, canvases, checkboxes and all kind of WPF controls.
I want to test if it adds any value to use 3D acceleration hardware on the Citrix servers because we are about to order new hardware and I am not sure if it is worth spending the extra money.
Some info is given away by Citrix on link below so I think of writing WPF "hungry" test app but I am not sure what it should look like.
http://support.citrix.com/proddocs/topic/xendesktop-7/hd-3d-gpu-acceleration-win-server-os.html
EDIT
Any idea what this WPF app should look like so I can make sure it uses GPU or is there a better way to test this? Which wpf controls should I use in the test app or is there similar test app written already?
Many Thanks
As a general rule, the composition of your WPF app will not affect whether the CPU (software rendering) or the GPU (hardware rendering) is used. WPF will always use hardware rendering when it is available on the machine, and will fallback to software rendering if it can't find hardware support.
Having said that, there are some things that WPF will always render using software rendering. E.g. the legacy effects derived from BitmapEffect.
You can use the WPF perf tools to see whether software rendering is being used:
http://msdn.microsoft.com/en-us/library/aa969767%28v=vs.110%29.aspx
The Perforator tool has an option to highlight sections of the app rendered in software with a purple tint.
So to answer your question, pretty much any WPF app you can create will use hardware rendering, just don't use anything derived from BitmapEffect. You can double check that software rendering isn't used by running the app on your desktop first and using Perforator to profile it. Once you've confirmed it doesn't use any software rendering you can test it in your Citrix environment with/with-out 3D hardware installed to see what kind of performance improvements you get.
I need to capture the visual output (like a screenshot) of a DirectX window.
Currently, I use this approach.
But, when the window is in background, it captures whatever is in front of it.
I see that DirectX windows render even when minimized or in background, so this should be possible.
But, how? (It also needs to be fast, and it needs to work on Windows XP too, unfortunately...)
Edit: I am very busy these days... Don't worry, I'll put the bounty back if it expires.
To capture Direct3D windows that are in the background (or moved off screen), I believe you have the following options:
Inject and hook Direct3D within the target application via the link you have already posted or this more up-to-date example (EasyHook can be difficult to get setup but it does work really well) - you can always ask for help about getting it working. I have used that technique for capturing in a number of games without issues (most recently for an ambilight-clone project). The problem with this approach is your concern about game protection causing bans, however FRAPs also uses hooking to achieve this, so perhaps your concerns are exaggerated? I guess gamers being banned for a screen shot is an expensive way of finding out.
For windowed applications on Vista/Win 7 - you could inject and hook the DWM and make your capture requests through its shared surface. I have had this working on Vista, but have not finished getting it working on Windows 7, here is an example of it working for Windows 7 http://www.youtube.com/watch?v=G75WKeXqXkc. The main problem with this approach is the use of undocumented API's which could mean your application breaks without any warning upon a windows patch release - also you would have to redo the technique for each new major Windows flavour. This also does not address your need to capture in Windows XP.
Also within the DWM, there is a thumbnail API. This has limitations depending on what your trying to do. There is some information on this API along with other DWM API's here http://blogs.msdn.com/b/greg_schechter/archive/2006/09/14/753605.aspx
There are other techniques for intercepting the Direct3D calls without using EasyHook, such as substituting the various DLL's with wrappers. You will find various other game hooking/interception techniques here: http://www.gamedeception.net/
Simply bring the Direct3D application to the foreground (which I guess is undesirable in your situation) - this wouldn't work for off-screen windows unless you also move the window.
Unfortunately the only solution for Windows XP that I can think of is intercepting the Direct3D API in some form.
Just a clarification on Direct3D rendering while minimised. During my fairly limited testing on this matter I have found this to be application dependant; it is generally not recommended that rendering take place while the application is minimized (also this reference), it does continue to render while in the background however.
UPDATED: provided additional link to more up-to-date injection example for point 1.
A quick google and i found this Code Project which relates to Windows XP. I dont know if you can apply this knowledge to Windows Vista and 7??
http://www.codeproject.com/Articles/5051/Various-methods-for-capturing-the-screen
EDIT:
I found this article as well:
http://www.codeproject.com/Articles/20651/Capturing-Minimized-Window-A-Kid-s-Trick
This links off from Justins blog post here from the comments. It seems he was working on this with someone (i see thats your link about).
http://spazzarama.com/2009/02/07/screencapture-with-direct3d/
The code that you linked to (from spazzarama), which you said you were using in your project, captures the front buffer of your DirectX device. Have you tried capturing the back buffer instead? Going from the code on your linked site, you would change line 90 from
device.GetFrontBufferData(0, surface);
to
Surface backbuffer = device.GetBackBuffer(0, 0, BackBufferType.Mono);
SurfaceLoader.Save("Screenshot.bmp", ImageFileFormat.Bmp, backbuffer);
This would also involve removing lines 96-98 in your linked example. The backbuffer might be generated without the obstructing window.
EDIT
Nevermind all of that. I just realized that your linked sample code is using the window handle to define a region of the screen, and not actually doing anything with the DirectX window. Your sample code won't work around the obstruction because your region is already drawn with the other window in front of it by the time you access it.
Your best bet to salvage the application is probably to bring the DirectX window to the top of the screen before running the code to capture the image. You can use the Wind32API BringWindowToTop function to do that (http://msdn.microsoft.com/en-us/library/ms632673%28VS.85%29.aspx).
I have a WPF application in which I put a check for the rendering tier and on my dev machine it reports Tier 2 every time. As far as I know this means that it has full hardware rendering capability. Which it should, it's a new system running an Nvidia 550M chip. But when I check with WPFPerf, it shows that the entire app is rendering in software mode! What can I check to figure out what is causing this?
One thought is could it be that I have AllowTransparancy set to True? (It's a borderless window, so I had to use it).
NVidia 555M? That sounds like Optimus issue. I had this issue with some games - the GPU-chooser doesn't detect a performance intensive application and runs it on the GPU integrated in CPU.
I never had this issue with a WPF app though (I think the integrated GPU should be tier 2 as well, at least it appears to be on my Core i7).
Try going to NVidia Control Panel -> Manage 3D Settings -> add your application there. If you are using VS debugger, add the X.vshost.exe as well.
I have a wierd problem that i need to work out how to resolve,
I have spent the last couple of weeks working on a project for work on my laptop, but when I open the program on one of the work pcs alot of the controls are the wrong size and over lap etc,
the differences between the machines is this:
Laptop:
Windows 7 Pro;
Display - 1920*1040;
Visiual Studio 2008;
.net framework 3.5
Work Desktop:
windows xp pro;
display: 1024*768;
visual studio 2008;
.net framework 3.5;
to discribe the problem better, i have a panel which i have set to be 300px wide, which has a label inside with the day and the day in the mm-DD-yyyy format, using arial and size 8 font.
On the laptop it all fits perfectly but on the desktop the panel seems smaller and the label only displays half the text.
That is just one of many problems, another is with colour system.control seems to be a completly different colour between systems (althoug I figure that to be a win7 vs xp problem)
What can I do to fix this?
is it a windows version problem? (I have xp on a vmware machine on my laptop so i could code and design in that)
is it a display problem? - this is a big problem for me as i only have 1 laptop and I think this problem could have caused me mark loss on my recent assignment for Uni (I coded on laptop and never opened on a desktop untill today - so had no idea of this problem)
EDIT: I have found a solution of sorts for my particular problem, I discovered that my laptop was working on 125% on the dpi settings for visually impaired (no idea how..) so I have reset it back to 100% or 96Dpi Which has fixed my problems, and after chatting to a couple of other developers I know, they say that they tend to design for 96 dpi while leaving a little bit of white space around text to be safe. but then they don't tend to use c# much and mainly code all in c++ using QT framework.
The video adapter in your workstation has a different dots-per-inch setting. The form automatically rescales itself to accommodate that.
This is going to happen as well when you ship your product and it will run on the client's machine. Changing the form's AutoScaleMode property is not a fix, that will just produce clipped text in the controls. Make sure you form design is resilient to layout changes. Dock, Anchor, TableLayoutPanel, FlowLayoutPanel, the Resize event for tough cases. And make sure the controls inherit their container's Font property (not bold in the Properties window)
Ensure you can resize your panel in Visual Studio with all of the controls inside it being repositioned and resized properly. You can use anchors to achieve this, or perhaps you should use a TableLayoutPanel control instead of a regular Panel.
Change your setting for AutoScaleMode.