I'm trying to make a software that displays various GIFs in PictureBox on transparent form background. Everything's fine so far, but there is one difference when I run the program on different systems.
I'm writing it on Win10 64bit laptop with .NET framework up-to-date and the transparency and animation is fine. It's just PictureBox GIF on form that's set with same TransparencyKey as its background Lime color.
I made sure to target .NET 4.0 as I heard that's the last one supported by Win XP. When I transfer it onto my other testing system (VMWare XP SP3, DX9, .NEt 4.0) the form Lime background is visible in the PictureBox area, other parts of the form remain transparent.
How can I get the GIF with transparent background to be displayed on XP desktop using WinForms?
Is this even possible on XP with WinForms? It is not mandatory to make the project for XP but it is highly preferred as the target system is going to be quite weak.
I'd like to thank Hans Passant, as his comment gave me an idea which seems to do the trick.
'A completely wild guess is that it is actually the background of the image that matters and not the background of the picturebox. And the virtual graphics adapter is operating at a lower bit depth, like 8bpp or 16bpp. – Hans Passant 19 hours ago'
I changed all the 'Lime' colors and Transparency Keys mentioned in the code into 'White', and it works fine now...
Related
I am developing a Windows Forms application using VS2008 on Windows Vista. I tried to run my application on Windows XP the other day, and everything on GUI was messed up. I realized that I developed the application using 120 Dpi setting on Windows Vista and my XP was set to 96 dpi.
My application has several UserControls and all of them shrinks even in the Visual Studio itself if I change my DPI to 96. I am sure a lot of people are using Visual Studio in high DPIs these days. So how can make sure that my GUI does not get messed up both in Visual Studio and runtime?
EDIT: I have read couple articles on this issue and I learned that I should be setting AutoScaleMode to None. However, this still does not prevent my labels to adapt new DPI settings enforced by the operating system. I need a way to prevent my labels to grow/shrink because other GUI elements have fix sizes.
It has been a while since I worked on this issue, but try setting AutoSize = False. In addition, UseCompatibleTextRendering = True might help.
This is a rather old question, but I want to share my solution/opinion. I ran into a similar problem recently. Actually, I want Visual Studio to keep my WinForms as they are, but them to scale at runtime. I found no consistent summary on how to correctly do that. After some reading and experimenting I came to this solution:
Keep the Form’s AutoScaleMode = Font.
Set in your Forms Designer: Font = MS Sans; 11px
In the Forms Ctor, after InitializeComponent, set: Font = SystemFonts.DefaultFont
Enable DPI-Awareness, either through a manifest or by API function SetProcessDPIAwareness
Since AutoScaleMode remains active, all DPI-changing magic works, even per-monitor DPI awareness. What remains, is designing Forms in a way scaling works nicely.
I wrote the details on my Blog: http://www.sgrottel.de/?p=1581&lang=en
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.
I was wondering: are you satisfied with the text-rendering in the Visual Studio 2010 editor (Beta 2)? On my primary monitor it looks very blurred, even when using font size 12!
When using font size 10 or 11 it's horrible. Can the WPF text rendering mode be set explicitly for VS code window?
EDIT: I am using Windows 7 x64 and my primary monitor is a Benq G2412HD. What's kind of strange is that the font seems to be nicer on the secondary monitor, which is a 4 year old 19' TFT.
EDIT: I tried several Cleartype settings but none really looks as nice as when using Visual Studio 2008.
The first image is from the primary monitor, the second from the secondary. Both are using Consolas 10pt (my preferred font).
Primary screen http://img4.imageshack.us/img4/6789/vs2010.png
Secondary screen http://img4.imageshack.us/img4/7986/vs20102.png
I use Consolas size 10 and I have no issues.
Try following the instructions on Microsoft's website for tuning clear type. You can find it here.
If you use IE when accessing that website, you can make changes to clear type settings right from the browser.
TextSharp is the answer right now. I really hope they continue to fix this issue because I've had terrible results on my primary and secondary monitors with the standard rendering. Using beta 2.
With 8 or 9pt Lucida Console the text is fine with text mode set to 'Aliased'.
Here is how VS2008 and VS2010 beta2 editor text rendering looks for me, side by side. The font is Consolas 13pt.
VS2008:
http://int19h.org/so/cleartype_vs9.png
VS2010:
http://int19h.org/so/cleartype_vs10.png
I don't see any observable differences.
[EDIT] Okay, I've reproduced it with the color scheme posted. It seems that the key part here is to use bright text on dark background. With dark-on-bright, the output seems to be the same.
Here's some guesswork. Apparently, Direct2D (which WPF uses for antialiased text output) always "gives precedence" to foreground (i.e. text) color over background color when doing subpixel antialiasing. On the other hand, traditional GDI ClearType seems to always give precedence to dark colors over bright ones. Thus, with bright letters and dark backgrounds, ClearType text becomes thinner, but Direct2D text remains of the same size, pixel-wise. Furthermore, as bright pixels are more intensive, the same amount of them "stands out" more with same foreground/background contrast, so bright-on-dark D2D text looks noticeably "bolder".
Well I experience the same oddity (not only in VS2010, but in all WPF applications). Sadly there seems no way of setting a "backwards style" text rendering in WPF in general.
I just found this addon "Text Sharp" for VS2010 on the VS gallery which lets you select different font aliasing options for the VS2010 text editor, but at least for me, this didn't help with the issue.
Here is the link, if you might want to try it: Text Sharp VS2010 extension
Please have a look at the screenshots in the following update (to come in final release of VS2010), and see if the improvements solve your issues with VS font rendering:
http://blogs.msdn.com/text/archive/2010/03/05/additional-wpf-text-clarity-improvements.aspx
http://blogs.msdn.com/visualstudio/archive/2010/03/11/wpf-text-clarity-improvements.aspx
Have you ensured that ClearType is enabled on your OS? I've seen similar issues with 2010 when ClearType was disabled on my machine. Re-enabling ClearType made the Text snappy looking again.
For some reason the ClearType setting on my OS kept getting undone when I TS'd around a bit. I had to reset it a couple of times but it seems to have calmed down recently (I believe I was using a Pre-RTM build of Win7 at the time).
Try using Courier New font.
Tools -> Options -> Environment -> Fonts and Colors
ollifant I agree with you, they are different.
Others may not see any differences from screen shots, but on the actual machine I can see differences. Loading the same project with the same settings side by side looks different. I think it is the difference in how WPF renders fonts or something.
The VS 2010 pane looks shifted slightly left, like kerning in the font is off by a little or something. Again - same font in both VS 2008 and 2010.
I have tried now on Windows 7 and Windows Vista. Maybe older XP machines render differently, can't say (and no I won't load XP to find out).
I have noticed a rendering problem with Visual Studio 2010b2 as well.
I've tried adjusting the clear type settings to no avail.
I use consolas 9 pt on win7x64 with a average 19 inch TFT.
This is what it looks like on my system.
A side by side screen shot
OK here's what you do. Finally figured it out!
You need to reset cleartype to the default values. Don't try to tune it based on what you think looks good - because what you think looks good won't in VS2010.
I noticed on a brand new install of Windows 7 my VS2010 text suddenly became a lot nicer. After running cleartype to try to get nice text on a wall mounted Sony TV I found it had totally screwed up text for my normal external monitor.
I haven't yet found a way to reset cleartype explicitly, but apparently the below explains what the defaults are :
When you open ClearType Text Tuner,
select "Turn on ClearType" check box
and click on Next. Then, again click
on the Next after setting Native
Resolution. Then, select the options
as given below:
1st Screen – 1st Option out of 2
2nd Screen – 2nd Option out of 6
3rd Screen – 1st Option out of 3
4th Screen – 2nd Option out of 6
Finally, click on Finish.
This is for VS2010 RC.
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.
Under Windows XP WPF true 3D content (which is usually displayed using the Viewport3D control) looks extremely ugly because it is by default not antialiased as the rest of the WPF graphics are. Especially at lower resolution the experience is so bad that it can not be used in production code.
I have managed to force antialiasing on some Nvidia graphics cards using the settings of the driver. Unfortunately, this sometimes yields ugly artifacts and only works with specific cards and driver versions. The official word from Microsoft on this regard is that antialiased 3D is generally not supported under Windows XP and the artifact I see result from the fact that WPF already does its own antialiasing (on XP only for 2D).
So I was wondering if there is maybe some other secret trick that lets me force antialiasing on WPF 3D content under Windows XP.
Have you tried this (from your thread on MSDN forums)?
Well, it seems the reference in the MSDN link above incorrectly specify the affected registry root key. In MSDN it is specified as HKEY_CURRENT_USER, while the correct root key should be HKEY_LOCAL_MACHINE. I've tried setting up the HKEY_LOCAL_MACHINE\Software\Microsoft\Avalon.Graphics\MaxMultiplesampleType to '4' and I can get antialiasing for my WPF Application on XP.
The feeling I get from Matthew MacDonald's Pro WPF Windows Presentation Foundation in .NET 3.0 is that it's not possible:
There's one exception to WPF's software support. Due to poor driver support, WPF only performs antialiasing for 3-D drawings if you're running your application on Windows Vista (and you have a native Windows Vista driver for your video card).
I've never seen anything to suggest that you can enable AA in WPF 3D on anything but Vista, but if there is a way it's new to me and I'd love to know as well!
Does your video card support Shader 2.0? You can refer to this wiki page to see if it does...