I'am testing a WPF application, and I have noticed a strange issue.
I am using duel monitors one is using the 32bit High colour, the other is using 16bit Medium colour. This is so that I can match the resolutions nicely.
If I open the application on my high colour screen I have no problems, but if I open it on my medium colour screen I get a terrible graphics lag, as soon as I move the mouse over the application. It makes it impossible to use the app on this screen.
Is this likely to be a problem with WPF or the Application? and is there any way to fix it?
Thanks in advance.
This an issue with the graphics pipeline; it has been described by Raymond Chen.
In short, don't do that.
Avoid monitors with differing color depths at all costs.
Just had the same problem... A colleague found out, that the problem is the Windows-Transparency. If you deactivate that on the 16bit screen, it works.
Related
Im beginning in my journey of learning WPF. After a few days of coding I see that whenever I resize any WPF form I get a black border on the bottom and right while resizing, like an artifact, as if the screen is too slow. When working with winforms I never noticed this.
Like so :
Is this a known problem? any simple workaround?
EDIT 1:
Seems its related to the graphics driver, I only work on laptops with weakish gfx cards, so does anyone else have this issue? (Im also using Win7 SP1)
It's a known problem, and it's unlikely that it will be fixed. There is a work-around that reduces the impact of this problem if your background is sufficiently uniform: https://stackoverflow.com/a/14309002/33080
My understanding of the underlying cause is that WPF controls lag behind on resizes: WPF draws them in the "wrong" location briefly. See the linked question for a demonstration.
If you resize a window it has to redraw. This takes some time and also it occurs after the window manager already resized your window and shows it; in that case you'll get a black border in WPF and one with the normal window background (grey, usually) in Windows Forms.
Usually all you can hope for there is that the computer is fast enough with the redraw to not show it.
I am getting very strange flickering on a WPF application of mine. It only happens with alpha blended content, only on my computer, and only with WPF applications. At least I haven't noticed it with anything else. It's really annoying! Has anyone else dealt with this weirdness?
Try disabling hardware acceleration to see if that resolves the issue. If it does, try updating your video card drivers and turning back on hardware acceleration. For more details, see here:
http://msdn.microsoft.com/en-us/library/aa970912.aspx
I'm in a situation that requires many animations with effects like transparency to be applied but when there are about 10 of them running, my application slows down to a grinding halt! :(
I also, tried implementing a particle like effect using a frame by frame manual animation using the CompositionTarget.Rendering event, which changed an Image's Source property at a given framerate. Again, this works fine for the first few instances of the particles on the screen, but when more and more get added I need it to stay performance wise, which is always a tough ask for any application
I was wondering if anyone has any experience using pixel shaders in WPF for animations, or perhaps custom writeablebitmap's for animations?
I basically need to palm off most of the animation processing to the GPU if possible...
Thanks for any help you can give!
Cheers,
Mark
If you want performance you should think about using XNA instead.
Then, you can add the XNA project into your WPF app
After reading the wikipedia article on WPF architecture, I am a bit confused with the benefits that WPF will offer me. (wikipedia is not a good research reference, but i found it useful). I have some questions
1) WPF uses d3d surfaces to render. However, the scenegraph is rendered into the d3d surface by the media integrated layer, which runs on the CPU. Is this true ?
2) I just found out by asking a question here that bitmaps dont use native resources. Does this mean that if i use alot of images, the MIL will copy each when rendering, rather than storing the bitmaps on the video card as a texture ?
3) The article mentions that WPF uses the painters algorithm which is back to front. Thats painfully slow. Is there any rational why WPF omits using Z-buffering and rendering front to back ? I am guessing its because the simplest way to handle transparency, but it seems weak.
The reason i ask is that i am thinking it wont be wise for me to put hundreds of buttons on a screen even though my colleagues are saying its directx accelerated. I dont quite believe that whole directx accelerated bit about WPF. I used to work on video games and my memory of writing d3d and opengl code tells me to be cautious.
For questions #1 and #3 you might want to check out this section of the SDK that discusses the Visual class and how it's rendering instructions are exchanged between the higher level framework and the media integration layer (MIL). It also discusses why the painters algorithm is used.
For #2, no that is most definitely not the case. The bitmap data will be moved to the hardware and cached there.
I tested that, I wrote two programs that show 1,000 buttons on screen, one in WinForms and one in WPF, both worked just fine.
I then pushed that up to 10,000 buttons, at that point the WPF app took a few seconds to start but run just fine, the WinForms app didn't start.
Win32 itself (and WinForms) isn't built for applications with hundreds of controls (believe me I wrote such an app), at some point it just stops working, WPF on the other hand, keeps working even if it slows down a bit at some point.
So, if you do need to put a lot of controls on screen WPF is your best bet (unless you want to roll your own UI framework - and you think you can do better than the entire MS perf team).
Also, WPF has many advantages other than graphics acceleration: richer graphics, drawing model that is easier to work with, animations, 3d and my personal favorite - amazing data-binding.
This will let you develop richer UIs faster - and I think that will make a much bigger difference than the painting algorithm used.
BTW, if you need to put hundreds of buttons on the screen this is likely to be a bad user experience and you may want to reconsider your UI design,
I have a Silverlight control that tries to have the same background as the underlaying div, but I'm facing color difference problems in IE7/8:
That doesn't seems to be a problem for Firefox.
Does anyone has a tip how to solve this problem? I try to avoid using the windowless mode in Silverlight and alpha transparency as 1st) it's slower and 2nd) shows a bounding select box when you click in the control in Firefox.
Fortunately I managed to solve the problem. Seems that it's a gamma correction problem. The PNG file allows you to set gamma correction information and Silverlight and IE seems to handle it differently.
This page explains the problem and saved the day. This tool as also necessary to remove the gamma information from the PNG.
Hopefully this information will be useful for someone.