I'm developing an application on a tablet using Silverlight out-of-browser with portrait orientation.
However, when the tablet is turned to landscape mode, the application also turns, and all the alignments are thrown off.
I found a post (http://stackoverflow.com/questions/8323318/wpf-orientation) that provides the solution for WPF, but the Microsoft.Win32.SystemEvents namespace is not available in Silverlight.
So is there any way I can lock my Siverlight OOB application to a single orientation?
Thank you!
In WPF you could provide a rotation layout transformation to the root container. It isn't actually locking the orientation but rather rotating your application. In Silverlight which as far as I know only supports render transformation, this would be much more difficult to do without other adverse effects.
I'm not aware of any public API to lock the screen orientation. Mostly because typically, Tablet PC manufacturers provided their own preinstalled utilities or drivers that used accelerometer data to change orientation. It was not a built in OS function. This may be changing in Windows 8.
Related
I am a bit confused about per-monitor dpi-aware in WPF. I thought you need to do some work to make your windows scale properly on different monitors (as described in Developing a Per-Monitor DPI-Aware WPF Application).
But I've just ran my app on pc with two monitors (2560x1440 and 2160x1440) and the dialogue would automatically scale itself when I move it between monitors. That's on the latest fast ring Windows 10. Am I missing something?
What you see is an example of System scaling when one app window moves to a different monitor with a different DPI. That is because WPF apps are by-default System DPI Aware. As a result, if you notice carefully, you'll see WPF visuals/text gets blurred when the target DPI is higher or they look fuzzy when the target DPI is lower.
Also, note that monitor resolution does not matter for WPF apps, since WPF is device resolution agnostic (it's measurement unit is Device independent Pixels).
Good news : .NET 4.6.2 preview just got released and it hasPer Monitor DPI Awareness out of the box. Check out the developer guide and samples here :
https://github.com/Microsoft/WPF-Samples/tree/master/PerMonitorDPI
Continuing the conversation from comments.
Yes that is the same for Windows 8.1.
And here is the note from your linked post
Windows Presentation Foundation (WPF) applications are by default system DPI-aware.
HTH
I'm trying to create a WPF application that makes a Skype video call with the use of Kinect gestures (Kinect SDK v2.0). I want to use the Kinect color camera in the video call, while still be able to use Kinect in my WPF application to detect the "hung up" gesture. Is there a way to do this? While the Skype video call is active, I don't really need Kinects color stream in my WPF application. I just need the Body stream to detect the gestures. I'm using the Kinect for Xbox One.
Sure. It works out of the box like that.
The SDK 2.0 is designed specifically to enable "simultaneous multi-app support":
Improved multi-app support enables multiple applications to access a
single sensor simultaneously. - Developing with Kinect: Simultaneous multi-app support (on the very bottom)
There isn't anything special you have to consider. Since the SDK doesn't allow you to change any camera settings (like exposure time or gain), your applications basically just have read-access to the SDK, so they can't interfere with each other.
Just develop you applications separately and run them at the same time.
In earlier versions of WPF setting Window.AllowsTransparency or using BitmapEffects (the deprecated ones), or TileBrush usage, apparently could cause WPF to switch to a software rendering mode instead of hardware rendering thus affecting performance dramatically.
I found this list, but it is from 2010.
Are there any potentially common cases that could cause software rendering to occur in framework 4+? Assume the hardware is sufficient, purely software related.
This list is still accurate.
This is covered on MSDN's page regarding Graphics Rendering Tiers. The second labeled as "The following features and capabilities are not hardware accelerated:" lists the specific criteria that can cause non-accellerated rendering in WPF.
This includes:
TileBrush
Content rendered via RenderTargetBitmap
Any printed output
Surfaces exceeding the graphics hardware's maximum texture size
Layered windows on Windows XP.
The following blog post by Dwayne Need seems to suggest that layered windows on Windows XP now are hardware accelerated.
http://blogs.msdn.com/b/dwayneneed/archive/2008/09/08/transparent-windows-in-wpf.aspx
DirectX does provide the IDirect3DSurface9::GetDC method, which can
return a DC that references the DirectX surface. Unfortunately there
was a restriction in DX9c that would fail this method if it were
called on a surface that contained an alpha channel. Of course, the
entire point of our layered window API is to enable per-pixel
transparency. This restriction was lifted for Vista, but our initial
release forced WPF to use its software rendering fallback with
rendering to a layered window on XP. We were able to lift this
restriction for XP too, which we released as a hot fix (KB 937106).
This hot fix was also included in XP SP3, so go get it! Now, on XP,
we can render via DirectX and pass the results of
IDirect3DSurface9::GetDC directly to UpdateLayeredWindow. On good
video drivers, the resulting copy will remain entirely on the video
card, leading to excellent performance. Some video drivers, however,
may choose to perform this copy through system memory. The
performance on such systems will not be nearly as good, but should
still be reasonable for many scenarios.
I tested this out by running the Perforator tool of the WPF Performance Suite (and checking the check box titled 'Draw software rendering with a purple tint') ... on a layered window application ... and everything seemed to be hardware accelerated (no purple tinting).
The recent MSDN documentation on Graphics Rendering Tiers still says (as Reed Copsey points out) that it should be software rendered, but that is not what I'm experiencing.
I have a WPF application that is intended for overlaying a HUD in a live stream. The original idea was to create a plugin for xsplit (a popular application for presenting live streams) to display the content of the WPF application. The problem with this approach is that rendering a bitmap to the COM interface of xsplit is far to damaging in CPU performance to release the application (As I believe there are issues in xsplit's COM interface as well as using RenderTargetBitmap taxing the CPU).
I've been looking at directly rendering the overlay into the game (The target DirectX application) because it provides a number of benefits. Chiefly it circumvents the performance problems in xsplit, but also opens the application up to a variety of streaming and capture applications.
I'm not a very experienced with DirectX but I think this is the outline of the solution
Initialize the WPF application and capture WPF's Direct3d device (via this method)
Find and hook the target DirectX application's EndScene call (using EasyHook+Slimdx)
Render contents of the WPF Device's surface ontop of hooked DirectX application
The main question I have is how to accomplish step 3 using SlimDX. I'd hope a solution could somehow reuse the surface and not rely on copying as the goal is to not impact the performance of the hooked application. I'd also like to be able to limit the region and support transparency. I am also wondering if using WPF's Direct3d device in the hooked DirectX application's device might cause any instabilities.
Any insight would be appreciated, thank you.
I'm trying to do the same. What I've found so far is that you can render your wpfvisualtree to a bitmap and afterwards write is bitmap to the d3d device captured in point 2.
void render(Direct3D.Device device)
{
wpfRenderTargetBitmap.Render(WpfVisualTree);
wpfRenderTargetBitmap.CopyPixels(devicePtr);
}
I didnt test this yet but I think I'm on the right track with this. The only problem I now have is that I loose all interactivity from my window. Button clicks and so on will no longer be captured...
Any help on that would be nice.
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.