I'm trying to use the MediaElement control in WPF to play back video. It works great in Vista, but when I run it on an XP machine I get tearing in the display. It looks as if it's not using the vertical synch, and just updating the screen mid-draw.
Anyone know how to fix this problem?
This has more to do with the way WPF renders to the screen under XP compared to Vista. Under Vista, apps render to an offscreen buffer which is then composited with other windows that have changed and is presented to the screen at the appropriate intervals by a process called DWM.exe. That can (and presumably does) present WPF's window updates to the video buffer synchronized with the refresh interval.
On XP WPF uses DirextX to render straight to the screen and updates the video buffer whenever it wants to. There might be some way to get it to synchronise with the refresh interval, but I haven't looked into it because I don't use XP any more.
Related
Is there a way to prevent or disable video capturing of my WPF application? Probably some Win32 API calls or some mask over my WPF content. Or if it is imposible is there a way to at least prevent the most popular screen capture programs from recording what is happening in my WPF application?
To prevent an application from capturing window contents, you can call the SetWindowDisplayAffinity Windows API with a WDA_MONITOR affinity. While this prevents applications from capturing a screen, it will not prevent a user from whipping out their smart phone and taking a picture of the screen.
The API is available on systems running Windows 7 and later. It's also required that Desktop Window Manager composition is enabled. Turning off DWM composition will undo the effect, so you need to prevent users from turning DWM composition off. If you are running Windows 8 and later, this is not an issue, since Desktop Window Manager is always on.
I have ubuntu 12.04 and mono 2.10.8.1 in my Linux PC.
I have one .NET application which continuously capturing image from camera connected in my development board.
It is working fine without any issue if i don't move my GUI windows which is continuously capturing image. But when i moves the tab to another window and get back to mono GUI window at that time GUI can not be refreshed and doesn't display live image from camera.
Also, I have also put one panel in which some data like frames and seconds are also going to displayed fine when application is running properly without moving tab to another window. But when i moved the tab into another window at that time same issue caused here that frames are also not going to refreshed in to that panel.
SO, does any one have idea about what is happening in this condition?
Is there any limitation about mono to refresh GUI window or something else?
Please let me know if any one have update as soon as possible.
I am working on a Silverlight 4 out of browser (OOB) application on a Windows 7 tablet PC. The majority of the time, the program is in full screen mode. However, if the user rotates the tablet, the application rotates and stays full screen, but is scaled for the previous screen orientation. Taking the application out of full screen and putting it back into full screen rescales everything correctly. Is there any way I can detect when the screen rotates? So far I've tried the app's Resize, LayoutChanged and FullScreenChanged events and have a handler for the main page's SizeChanged event. None of these get fired when the application is rotated in full screen mode.
Per Josh Einstein's suggestion, I tried polling the ActualWidth/Height of the application on a timer. It looks like after the rotation, the ActualWidth/Height values returned from the Silverlight plug-in are the pre-rotated values. Only taking it out of full screen and putting it back in full screen will change the resolution of the plug-in. The HtmlPage.Eval hack didn't work since I am OOB.
The WP7 version of Silverlight has the OnOrientationChanged event, which doesn't seem to be available in the desktop version. Anyone have any ideas?
Great question but as far as I can tell, it doesn't seem to be possible. I tried changing the screen resolution in a virtual machine (orientation change is really just a screen resolution change that results in width being larger than height or vice versa) and could not trigger any layout events.
The issue seems to be that the Silverlight plugin itself is not resized. With an elevated out-of-browser application you could presumably use COM interop with WMI to get the actual screen resolution, but it's kind of hacky. If it's an in-browser application, you could use the HTML DOM. In both cases, you'll probably have to poll for the current screen resolution instead of being notified via an event.
Mister Goodcat has written a blog post about how to get at this information in both scenarios.
I would file it as a Silverlight bug too.
I am currently working on the WPF project which involves creating a touch-screen application for Windows XP embedded. And as Windows XP wasn't built for touch interaction, there are some problems and issues with developing those applications.
An example would be a click: On windows XP click is mouse down and mouse up event, however if you use your finger instead of the mouse, you might get a drag motion instead of the click, as when you press mouse down you finger might slightly move to the side from the initial position and you will get a drag instead of click. This is just a single example of the problems you get when developing an touch-screen app for Windows XP.
If someone has been working on the WPF touch-screen application for Windows XP, could you share some knowledge and point out the pitfalls you have encountered or if you know of any resources on this topic, could you please share it.
I would agree with #bflosabre91. With a mouse you could have the same problems and in fact happens quite frequently when someone is learning to use a mouse. I think this problem is more relevant at the hardware level and how the touchscreen actually interprets what the user is doing.
On the software side, you COULD add some logic something along the lines of:
On mouse down: record coordinates and maybe the control (button, etc.) that is under the pointer
On mouse up: compare recorded coordinates with current coordinates. If it's within x pixels, either do a "control.click" or move the mouse to the old coordinates and tell tell the mouse to click.
The hardware may already be doing something like this...
i have a WPF touch screen application and it is running on kiosks with XP(although its not XP embedded like you said). I haven't had any issue with any type of click event or anything like that. I programmed it using all the normal mouse click events so it technically does work with a mouse or with the touch screen. As long as you build the controls to be large enough to account for the fact a finger will be touching it instead of a mouse pointer, I did not come across any issues.
I'm having problems with the rendering of a WPF app over a remote desktop connection.
The applications chrome is rendering, but none of the content is coming through, as if the window is not drawing. Instead the previous content of the screen is showing in it's place.
This has been a problem with the application running on both Vista & Win 7, with remote control being taken from XP and Win7.
The problem is not application specific, if I create a new WPF app, with just a textblock on the window, it will also not run. (Neather will the windows preview in VS2008 display.)
Is there some trick to getting WPF running under RDP?
I read on Kevin Dente's blog (from a twitter post) that he was having trouble with WPF apps in virtual machines. While not the same as Remote Desktop, it's possible the problem could be the same. Kevin was able to fix his problem by disabling hardware accelleration by creating a DWORD registry value at
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics\DisableHWAcceleration
and then setting it to 1.
His original blog post is here: http://weblogs.asp.net/kdente/archive/2009/10/19/visual-studio-2010-beta-2-editor-performance-fix-running-on-a-virtual-machine.aspx
That may not be your exact solution, but maybe it points you in the right direction.
WPF should render over RDP; it's smart enough to know when it can render in hardware, and when it can't it reverts to its own GDI+ based software rendering. I would make sure you're running .NET Framework 3.5 SP1 on the remote machine, since there were changes to remoting that might pose issues. (See link below.)
I've been developing a WPF app for the past 6 months and it works just fine over RDP. (From Vista and Win7 to XP, Vista and Server 2003.) One important caveat, however, is that it renders using the Classic theme. So if you're using controls that don't have a classic theme, they won't render. If you're just dropping a TextBox on a Window, then obviously that's not your problem.
Check out this question for some links that may be helpful: Are there problems with rendering WPF over Remote Desktop under Windows XP?
I just had this problem with the ribbonwindow not displaying correctly when testing for the first time via RDP - the transparent background was white, the close minimize/maximize buttons were missing, the rounded corners on the bottom of the window were square, and the top row of ribbon buttons were almost impossible to select.
Turns out there was a simple fix for me. Right-click the RDP connection icon (I have it saved on my desktop), select "Edit", then the "experience" tab, and change "detect connection quality automatically" to "LAN (10 Mbps or higher)".
This fixed it for me.
Ade
Did you also try Win7 latest RDP - Win7 connection? The thing is WPF doesn't use GDI to draw elements.
VNC clients (like UltraVNC) probably will do the trick for you as they using much simplier algorithms more like of sending bitmaps.
I have the same problem than the asker. The standard, out-of-the-box Checkbox is not rendering correctly. I can only see if it is checked when hoovering the checkbox. Otherwhise, no difference between checked and unchecked. Important note : It occurs when setting the foreground to white (see here : https://social.msdn.microsoft.com/Forums/vstudio/en-US/1c03db49-7e53-4cbb-9dd1-b328017c4453/wpf-checkbox-and-radiobutton-check-mark-not-showing-under-xp-windows-classic-theme-and-remote?forum=wpf)
Our application used to have this problem with a custom progress bar.
We fixed this by setting the background color of the Border control to White. This leads me to think there is an issue with transparent backgrounds
There is no special trick needed to get WPF content to show across remote desktop. Our WPF-based app renders just fine over RDP (tried from numerous machines) with no problems. We're even using animations, gradients, WriteableBitmap, etc. w/ no problems.