windows forms scaling issue on high dpi display - winforms

I am having an issue with auto scaling while trying to create a Windows forms app. I'm currently running on a Dell laptop with a 3840 x 2160 display (4K). I'm trying to add an image to a picture box, and if I leave the picture at its native size (which is quite small on my display) it appears at a correct autosized scale when I go to run the app. The issue with this is at the native picture's size it is very difficult to lay out all the other items I want to add to the app. If I increase the size of the picture to something that is usable it increase the size of the image to something large enough it doesn't fit on my screen. I know this is likely due to the auto scaling Windows 10 does, but I wanted to see if anyone else might have a work around for this? I've tried to see if there is a way to zoom in the display in the designer window, but I haven't found anything. I have also noticed the size of the windows forms app itself changes depending on where I have items placed on it.

I don't know that I completely understand what you're asking, but I would assume it could have something to do with the pixel units of your elements. Here's an excellent explanation of point-based vs pixel-based sizing

Related

Touchscreen control size

How do you handle control size on touchscreen, so it is easily used?
I have seen most examples have TextBox Height set to 40 pixels, or buttons 40x40. So, when I make controls this size and use it on my 13" Full HD device. it is OK.
However, I have noticed that lately there are laptops with very high resolution (ex 3200x1800), and small screens (ex 13-14"). How do you handle such scenarios? They usually set text (app) size to 250% in display settings, although this is mandatory.
Do we programmers need to use text (control) scaling as parameter when building UI?
Writing a DPI–aware application is the key to making a UI look consistently good across a wide variety of high-DPI display settings. Applications that are not DPI–aware but are running on a high-DPI display setting can suffer from many visual artifacts, including incorrect scaling of UI elements, clipped text, and blurry images.
link: Writing DPI-Aware apps

Web App V Win App - Display differences

I have been searching for any info on this without success.
I am updating an application that has two versions. A WPF windows app and an MVC web app. The requirement is that they must look the same.
Why when I add an image of, say, 100px X 100px to both the image in the web app looks larger than the image in the win app?
If I add margins the space between the items looks more in the win app than it does in the web app.
I thought I was mistaken so I physically measured both and confirmed the differences.
I want the 100X100 image in both apps to look the same and do not want to up size as this will distort the image.
Can anyone explain why this would happen and any way I can get around it?
Many Thanks
Fred
Assuming no styling is being applied to the images either in XAML or CSS, they could still be different because WPF pixels are device independent.
I guess you could set the ScaleTransform of your WPF app to match the desired size, but remember this will be different depending on monitor size and Windows DPI settings.

What is the maximum width of current mobile browsers?

I am using a script from http://detectmobilebrowsers.com/ to detect whether a site is being viewed on a mobile browser.
If the site is on a mobile browser, I show a pared down, simple slideshow. If it is a regular browser, I show a whiz-bang super slideshow. I'd like to optimize my images, making them as small as possible on the mobile slideshow. My mobile slideshow is responsive, so it will shrink to fit in whatever window, but I don't want to make it any larger initially than it absolutely has to be.
Does anyone know what the maximum width is on the current array of mobile browsers? Or rather, the maximum width of mobile devices that are detected with the http://detectmobilebrowsers.com/ script?
BTW, I'm not asking how to detect the width once the page is loaded in a browser.
Thank you!!
Edit....
I think you guys misunderstood my question. I AM using max-width:100%. My images DO scale to fit any screen-size. And, I DO determine whether to show a simple slideshow or a complex one. Here's my logic:
If the user is using a mobile device (based on the device detector)
show a simple slideshow
Else the use is NOT using a mobile device (based on the device detector)
If this is a small screen (based on media queries)
show a simple slideshow
Else this is a large screen (based on media queries)
show a complex slideshow
End If (based on media queries)
End If (based on the device detector)
Why bother using mobile detection at all? Because even though for small screens I am only showing the simple, low-filesize slideshow on small screens, the images from the complex, image-heavy, high-filesize slideshow ARE STILL DOWNLOADED (http://cloudfour.com/examples/mediaqueries/image-test/). My media query determination of which slideshow to show doesn't save the user from having to download the images of the slideshow that's currently not shown. It's only used because the simple slideshow looks better on small screens than the complex one. Using the mobile detection screen makes sure that images that aren't shown, aren't downloaded.
Why do I care what the maximum width is on current mobile devices, when my images are set to 100% width and will scale down to fit any size? Because a 900px wide image has a larger filesize than a 600px wide image. If I know what the max width is that the image needs to be, I can save the slide down to that size initially, saving some additional bandwidth. Have you guys ever viewed a slideshow on a mobile device? Slow!
I would really appreciate if anyone can point me towards the proper stats. I googled, but couldn't find what I needed.
The answer is almost certain to change as soon as you deploy the software.
It also depends on whether you mean pixels or screen-resolution-pixels (the Retina displays define them differently).
Perhaps it's best to stick with detecting mobile browsers (if you don't like the scripts you're using, see , e.g.:
Detecting mobile browsers on the web?)
and then let users opt into higher-rez images.
Alternately, you could try to detect bandwidth, which is really what you're optimizing for; 'mobile' is just a proxy for this, and only moderately correlated with it.

Performance issue on complex WPF application, how to solve that?

I have my main window at something like 6000 x 6000 px. In that window, I can have a lot of controls (more than 5000) and we can zoom/pan where we want.
I added 10 "television screens" controls in my application, and each of them have a refresh rate of 100ms.
When I start this, everything crash...
10 objects with a refresh rate of 100ms each is too much, WPF cannot draw them at the time. I conclude that WPF is very slow to draw what I have....
Everything is drawn in vector, but I tried to add .CacheMode on them and it doesn't work either..
What can I do?
P.S. My PC is 8 core, 8 GB Ram, 256 Mb video card (nvidia quadro nvs 295) on win7 64bits
WPF uses software rendering in case you exceed maximum supported resolution of you graphics adapter. Moreover, 5k controls! Incredible. WPF is not a silver bullet for everything you imagine. You need to redesign your app or change technology you're using.
Work on reducing the number of controls in your application. 5K is quite a bit, and I think there is probably a way to reduce that number.
For example, use TextBlocks instead of Labels as TextBlocks render as 1 control while Labels render as 3 in 4.0 (I think its more than 3 in older versions)
Also, check and see if you can use UI Virtualization with some of your controls. Something like a ListBox of 100 items can be virtualized to only render 10 of them at a time.
Take a look at ZoomableCanvas - 1 million items. This is the best example out there of what WPF can do when using every optimisation in the book. I suggest you take that example and run it at the maximum resolution on your monitors. If that fails to perform well, then WPF cannot do this.
I was unaware that WPF default to software rendering if the resolution exceeds that of the video card. A good caveat to know about!
Regarding high performance graphical APIs I second Keiren and say use DirectX (SlimDX provides a managed wrapper) instead.

WPF high dpi issues

I created a simple web browser WPF test application with pictures and text within a canvas, with windows set at 96dpi.
Then I switched to 120 dpi and :-((( Display is messy, image size changed and part of the canvas is out of view...
When I used Winforms, I set the AutoScaleMode property to None and the windows keeps its size, the controls as well, the controls which have inherited font are properly displayed, not blurry and not too big...
What can I do to mimic this (good) behavior in W¨F?
I'm not clear on what you mean by "web browser WPF ... application". WPF doesn't run in a Web browser, unless you're talking about an XBAP. Or are you doing Silverlight? Or is it just a WPF navigation application and not browser-based at all? You'll need to clarify.
WPF automatically scales your content when you run in high-DPI modes. This is intended behavior: if the user explicitly says they want everything to be bigger on the screen, then WPF will respect the user's wishes. The old WinForms hacks of "pretend high-DPI doesn't exist, just show everything at the normal small size and hope it doesn't piss the user off too much" aren't available in WPF; you could probably emulate them if you worked at it, but you're steered very strongly toward doing the Right Thing.
WPF scales everything, so your statement that "part of the canvas is out of view" doesn't make sense. It should be scaling the canvas, its parent window, and its child elements all by the same amount, so if everything fits at 96dpi, it should also fit at 120dpi and 144dpi. If not, then you're doing something strange and you'll have to provide a code sample that reproduces the problem.
You seem to be claiming that fonts are blurry when you run in a high-DPI mode, which sounds very strange. Fonts are rendered as vectors, so they should scale cleanly, and render crisply even in high-DPI modes. I've never seen the blurry fonts you describe, so again, you'll have to provide a repro case.
The only thing that I would expect to be blurry are images. If you're using raster (bitmap) images (BMP / GIF / JPG / PNG) in your UI -- for example, for the icons on a toolbar -- then yes, those will look pretty bad when they're scaled. It pretty much always looks bad when you take a small bitmap and make it larger. You might try working around this by using larger images and sizing them down for display -- for example, if you want your toolbar images to be 16x16 (when in standard 96-dpi mode), then you could try putting a 32x32 bitmap in your project, setting the Image element's Width="16" and Height="16" in your XAML, and seeing if that looks any better. It would actually be 20x20 physical pixels in 120dpi mode, and 24x24 in 144dpi mode, both of which would still be scaled down from the 32x32 resource and would therefore have a better shot of looking good than a 16x16 source image that's had to be scaled up. (I haven't tried this technique in a WPF toolbar, though, so I don't know how well it would really work in practice with typical toolbar images.)
The very best way to get around the problems with scaling images would be to use vector images instead of raster. Unfortunately, it's hard to find libraries of vector images. They're few, far between, typically less comprehensive than what you can find for bitmap images, and often expensive.
Presumably you use fixed length units (px). Try re-layouting your project keeping the WPF layout rules in mind. This page has some best practices for that.
I just found a bug using MaxHeight under WPF in .NET 4, set in a Style that gets inherited by another Style and that is used as a StaticResource, which didn't get influenced by the DPI set by the user. I set it from MaxHeight to Height, then it got influenced by the DPI. I suspect a bug in the .NET 4 (and possibly other frameworks) here.

Resources