I have application in C# WPF (.NET4, app runs on Windows XP Embedded) and it worked correct, but now I received screenshot and there are graphical errors around text. These errors are only around text, not button edge, nor Windows desktop.
Images:
It is graphical error (hardware), or program error which can be repaired?
Try using:
TextOptions.TextFormattingMode="Display"
Which should use ClearType. Or you could try:
TextOptions.TextRenderingMode="Aliased"
..and see if you get better results
WPF should try to use ClearType and anti-aliasing by default to give a smoothed look out of the box. It cannot be turned off WPF Anti aliasing workaround.
There's a lot going on behind anti-aliasing, like sub-pixel anti-aliasing. http://blogs.msdn.com/b/text/archive/2009/08/24/wpf-4-0-text-stack-improvements.aspx. Edges are often aliased with another algorithm, that is hardware accelerated too: edge anti-aliasing. That maybe the reason you don't have problems with edges. For performance purposes the system tries to be smart and use hardware acceleration (all modern GPUs provide such). The thing what you develop is for some kind of commercial touch screen device seemingly: like electronic information booth at plaza/mall, or some control terminal in a factory, or something. These usually can have weirdo hardware in them, exotic GPUs and motherboards. Vibration and environment impact (hot day - cold night temperature change recurrence) can cause them to have glitches and hardware failures.
Try to run other software too on the device, which uses ClearType anti-aliasing like WPF does also. See if only your software causes that or not. See if other WPF software causes such.
You can try to turn off hardware acceleration if you can on that system, and see if software rendering improves anything.
http://blogs.msdn.com/b/text/archive/2006/10/18/tips-for-improving-your-wpf-text-rendering-experience.aspx
Poke around in settings also.
Try to run hardware diagnostics and GPU tests, depending on what you can get to the device.
I would rule out font file corruption: that would probably make the font completely unusable, and you also report that the weird look comes with other fonts too, I don't think that all of them is corrupted. Try to run diagnostics for software error though.
Are there any effects being applied to the text? I've seen instances where a DropShadowEffect is applied to text - this renders well on some hardware, but on other users' machines, the text looked mangled. With the drop shadow removed it rendered nicely.
See, for example, http://social.msdn.microsoft.com/Forums/vstudio/en-US/f44bce57-d67f-46d3-8161-57c80a02e893/strange-blurring-issue-when-using-shader-effect?forum=wpf
Related
Does anyone know how to apply effects to the entire screen, in c# or any programming language.
I'm mostly interested in making the screen monochrome (specifically green-white instead of black white).
I know a cross-graphic card solution is possible because I found a program that can do it:
http://www.freedomscientific.com/products/lv/magic-bl-product-page.asp
Anyone knows how to accomplish something this or where to look?
Thanks !!
There is no easy Windows API to modify the entire screen contents. But this could be done at the device driver level.
Otherwise you have to resort to some Windows API tricks: place a "fake" window over the entire desktop, in a loop: grab the entire screen contents without grabbing fake window contents, do your processing to get the monochrome effect, then display that on the fake window. Yes, it's hacky and slow, but possible. Even more hacky, when you get mouse clicks to "go through" the fake window (lots of SetWindowsRgn calls).
So cross-platform here means using GDI, though some older DirectDraw APIs might work, in that case, you have a much easier time with hardware overlays (and better performance). Though I'm not sure how many cards actually support hardware overlays, and if newer versions of windows support the older DirectDraw APIs.
One more possibility is if the video card has a C# or C++ or C API, then you can do whatever you want with the card without writing device driver code.
Then there's CUDA, but I haven't yet tried that out. I know it's for stream processing on nVidia boards, but I wonder if it could get you an easy backdoor into the video display stuff.
To help people in the future who are interested in this:
This is possible with the Magnification API's color effect method. This allows one to use a matrix that can be applied to the whole screen.
NegativeScreen is an open source project that implements the feature you are describing in C#.
Unfortunately, this only works with affine transformations, as the API takes only an augmented matrices rather than a delegate or something.
I've written a WPF application (in Visual C# 2010 Express) that has 2 windows. The 1st has a various buttons, the other displays video using the MediaElement control. When a button is pressed, a video associated with it is played or stopped if it's already playing.
On my development machine (Windows 7, good graphics card, lots of memory etc), this runs fine. The only problem I've encountered is that when attached to the debugger it is very unstable but when run normally these issues go away.
Unfortunately when run on a much less powerful XP machine the videos run at 1-2fps. This is despite the fact that the videos run fine in Windows Media Player.
There seem to quite a lot of reports of poor performance for the MediaElement control (not to mention inconsistencies in what it can play) so I decided to look at some alternatives.
I tried a free library call WPF MediaKit (http://wpfmediakit.codeplex.com) that I thought might have some effect, however while I've got it to work on an XP machine, it resolutely refuses to display videos on my development machine despite using exactly the same code. I'm still hoping I can this to work but I'm not confident it will help given it's still using the MediaElement control behind the scenes.
I then tried using wmp.dll COM control (Windows forms rather than WPF) and even with the simplest app (new Windows Form project, WMP control added to form, and 1 line of code to set the URL on load) I get odd behaviour. With the debugger attached, it works across multiple monitors, but sometimes when it starts playing, it just repeatedly stutters over the 1st few frames and the only way to break it out of this seems to be to move it to the other monitor. If I'm not using the debugger, I don't seem to get the stutter issue but the video is only displayed on the main monitor, as soon as I move the window to the secondary monitor, it goes black.
So my question is has anyone experienced anything like the above and/or have a decent solution to it? It would be especially nice to find something that works consistently with and without the debugger attached!
Have you tried this library?
http://directshownet.sourceforge.net/about.html
There's also this .NET interface to VideoLAN media player, but that introduces a dependency to VLC:
http://wiki.videolan.org/.Net_Interface_to_VLC
WPF MediaKit does not use MediaElement behind the scenes, but instead uses the D3DImage interop class to provide high performance video to WPF.
WPF in XP has always been a hit-or-miss in terms of performance. You might want to take a look at the rendering tier to ensure WPF is fully hardware accelerating. Also make sure you have the newest video drivers available and that the GPU is capable.
-Jer
I am developing an application using WPF. The app runs full screen, and I need it to resize nicely no matter the monitor resolution. The graphic designer has designed beautiful images for the UI buttons, backgrounds, etc. Using an Illustrator plug-in, all the images have been converted to xaml files. I've added all these images into the application, and they look great. I am also using a lot of Grid layouts so that the screen can resize while still maintain the layout. All of this is displaying as desired, nothing looks stretched when run at a different resolution. However, screen transitions and UI interaction are slow.
I am wondering, is this is due to the heavy use of graphics? Am I using too many Grid layouts? But, I need the Grids so that I can have resolution independence.
The application runs fine on my development machine, but is very noticeably slower on machine with lower performance capabilities. Yeah, this is to be expected, but not to the degree that I'm seeing. My employer insists the application runs smoothly on these lower performance machines.
I've done some profiling of the application and it seem that what takes the most time is the display stuff (though I'm not sure I fully understand how effectively to use a profiler).
If it is the WPF that is causing the slowdown, what can I do to improve this?
You can drill into which WPF activities are using up time using the Performance Profiling Tools for WPF. Assuming a heavy graphical load is causing the slowdown, this should give you some help as to what might need to be simplified (e.g. layouts) or removed (e.g. bitmap effects (these are a classic perf killer, though I don't want to prejudice your profiling!)).
If it is the WPF that is causing the slowdown
Probably not ;)
It is much more likely that it is your code that causes the slowdown. WPF is powerful, but you have to understand the core concepts to make it work well... You should have a look at this video from a PDC session, it provides lots of advice on how to make your WPF application faster
Convert your XAML Vector Images of buttons into Transparent PNG Images. Path and Shapes are very heavy to render, calculate and resize. Mostly after deployment, the images never change its better to have them as raster then vector, unless you want to perform smooth animation of changing shape, size or other attributes.
Grids are very costly layout managers as compared to Canvas, DockPanel. You can certainly think of replacing certain grids with DockPanel sometimes, but yes its not an easy fix it requires lot of brainstorming.
Avoid Panel with Single Child. Try to reduce Visual Hierarchy.
Use more of fixed size for buttons and such small elements, if you specify fixed sizes of children, it becomes easy for Panels to do layout processing.
In general, WPF is perfoming much worse in drawing performance than Windows Forms, and native GDI or DirectX.
Yes, WPF is powerful in the sense you might make some neat stuff that is not supported in GDI, but it is more sluggish.
If you are having much drawing to do, and you want to support it on slow hardware, then WPF is not a good choice.
WPF performance depends heavily on the quality of the video card in the machine more that the processor/memory. Bad video card = bad WPF performance.
Well, this is a long shot: when I installed VSTS 2010 (and it uses WPF) it was very slow on a Windows 2008 server with enough CPU/memory, and very fast in a more modest notebook. We managed to disable hardware acceleration and it became notably fast into that machine.
Maybe you do want to try this configuration, as it is very simple: Visual Studio 2010 Beta 2 editor performance fix running on a virtual machine
I work with a Dell XPS M1710. The laptop has lights in the lid, the side speakers, and the front speakers (3 sets of lights that can be individually adjusted) and a light under the mousepad. In the BIOS I can change the color of these lights, at least, each group. Also, I can turn a light on/off under the mousepad, I can't change it's color, just alternate if it's lit. The laptop came with a lot of software from Dell, but I've installed Windows 7 and lost all of their apps, including one that allowed me to change these light colors. Now that Dell's app is gone, I'm interested in making my own C# application to change the color of these 3 sets of lights (I don't particularly care to change the light under the mousepad, I like it off). How would I go about developing an app to retrieve and change these BIOS settings?
We released an SDK for the community:
http://www.dell.com/html/global/xps/lightfx/index.html
(I can say "we" because I worked on it!!)
Offers an extensive library of
functions for building custom effects
using the XPS M1710 LED lights.
Allows you to build custom effects
just by creating a text file with a
few simple XML tags -- even if you
are not an XML programmer.
Includes application programming interface
(API) functions that allow you to
program lighting effects directly
into applications.
Highlights
several sample effects to inspire you
to new heights of creativity.
From what I've been able to find, this hackery is done in SMBIOS.
Looks like this developer figured it out -- he's written a Python GUI on Linux.
I read the source, and he's hooking to dellLEDCtl in libsmbios to do the dirty work. Here's the source, if you can stomach it. The git repo that Dell provided to the community for this stuff is here.
I don't think you're going to get this done completely managed.
Does WPF use the installed color profile in windows for correcting the colors that are rendered?
I'm pretty sure old forms/gdi-based applications are not "automatically" color corrected, but I wonder if WPF does (or can be made to do) this automatically?
(I know I can do this manually in my own WPF apps by creating a gpu shader to do the color correction.)
The reason I ask is because more and more monitors are now wide gamut, this means that colors that look "normal" on "old" monitors will seem much more vibrant on wide gamut monitors. An example is my new monitor which has much stronger red and green colors than my other monitors.
I can correct this problem on a per-application basis for some applications (firefox, photoshop, media players using a custom shader etc.., my own wpf apps using gpu shaders..) but it would be nice if there was a way to have WPF do it automatically for all WPF applications.
It is not a big problem but it is however annoying and I had hoped that Microsoft would take the opportunity with WPF to introduce color correction by default.
edit: question clarified for posterity.
Nope. You have to implement it yourself in your app. Just like the the old forms/gdi apps.
I think this is a pretty big problem! The only application I have which supports color profiles is photoshop and I'm hardly use that. In all other situations my new wide gamut display is much worse than the sRGB one it replaced.
At a 92% gamut the colors were a little over saturated, but displays keep pushing this up and are at 110%+ now. The farther they push this the worse these displays get in non managed apps. Since there are almost no managed apps then most of the the time these displays are very bad.
Each app impelmenting color management support does not seem realistic. This needs to be done on an OS or driver level. You mention that you can do this with GPU shaders, but I know of nobody doing that except for an unofficial plugin to an open source media player.