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.
Related
I am new in Appcelerator framework, I have developed one application in appcelerator, but that application looks good on IOS but for android its not look good.
I want to develop a screen which is responsive like html.
Is there any way to design appcelerator screen like responsive screen.
Thanks you.
Don't define width, unless calculated. iOS is fairly simple with only a handful different resolutions, on Android you never know what resolutions you might encounter.
Luckily, you can specify widths differently in Titanium than you can in HTML. For example
var view = Ti.UI.createView({
left: 20,
right: 20
});
This will make your view the width of the parent, with 20 padding right and left, the width will be calculated.
Also, always stick to native UI elements. So tabgroups, actionbar/navigationBar should all be used so you don't have to worry about cross platform support, styling and sizing of those elements.
Furthermore, most view should be put in ScrollView's when you don't know how tall the UI is going to be. It could fit on iOS, but not on a small Android device. Putting it in a scrollview will always fix the screen as the scrollview will automatically enable scrolling when the content is taller than what fits.
So conclusion
Width should be defined relative. Either with left/right properties, or calculated
If height of content is not yet known or not designed to be fullscreen wrap it in a scrollview
Stop thinking of apps as websites, start thinking of them as Apps. Layout works differently
Lastly, Appcelerator is the company, Titanium is the technology you're using :)
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
I have a mobile game developed by U3D and NGUI and targeted to platforms such as android and IOS, but there are so many mobile resolutions and aspect ratios change from 1.3 to event 2. My UI are designed under resolution 1136x640, and UIRoot Scaling style is FixedSize, Manual Height is 640.
I am not going to use anchors in NGUI widgets because distance is defined in pixels but not in percentages, when resolutions are changed, relative position of widgets are also changed, this is not what I want.
I refer this but still have no idea to handle this tricky problem perfectly, I need some suggestions on how to use NGUI in right way to handle different mobile resolutions.
The newest (3.x.x) NGUI allows you to use their new anchoring system. As you said, it is specified in pixels, however you can specify different targets and distances to different edges, and it will behave similarly to percentages.
Are you familiar with NGUI team videos explaining their new releases?
https://www.youtube.com/watch?v=6k5iIzKTEBQ
Some of the information there could be helpful, and playing with Custom settings of anchors either.
Another useful things is to create scaling script attached to root, which scales all elements down, basing on the detected dpi. If your UI is prepared for phones, you probably won't need all the buttons to take the same percent of the screen on tablets.
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.
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.