Cocoa uses a drawing system (user coordinate space) measured in "points" which are resolution independent...sounds great
While we need to be concerned with our app running in many resolutions, Cocoa is going to take care of that for us in (1) above...sounds too good to be true!
It does scale our controls as resolution changes...this is good.
BUT the screen size increases as my resolution increases...this is not good, I though we had a drawing canvas that was independent of the resolution!
What if the controls shrink to silly small levels as the resolution increases - should I be concerned about this?
To summarize: is their a "standard" resolution I should design for and then all automatic scaling by Apple will automatically look fine?
[Confused while reading the Apple Progammer Guide on the topic of Drawing]
You do not need to be concerned about this. The user is only allowed to select resolutions which make sense given the physical size of the display, so the standard controls will always be "large enough". You just need to test your app on Retina and non-Retina displays (and ideally both at the same time, with an external 1x monitor plugged on a 2x machine ; move your windows between the two screens and check that your images update accordingly).
Related
wxWidgets 3.1 claims to fix the Windows High DPI issues. It works too but I see blur UI (fonts/bitmaps) looks stretched.
I went through the https://learn.microsoft.com/en-us/windows/desktop/hidpi/high-dpi-desktop-application-development-on-windows
I did the manifest changes to make my application DPI-aware, it removed the blur effect but application layout went wrong, every layout looks smaller (unusable UI).
Note* issue more vigilant on 3K and 4K system. Hardcoded pixel sizes are not scaling (like 400px width button, 500pixel width panel etc).
wxWidgets gives you a (relatively simple) way to make your application work in high DPI, but doesn't -- and can't -- do it automatically for you, in particular only sizer-based layouts without hardcoded pixel sizes will work correctly and you do need to provide your own higher definition artwork.
Concerning the existing pixel values, the simplest (even though not really the best) way to make them work better is to put FromDIP() calls around them.
Also note that you don't need to do anything special for pixel values in XRC, they're already interpreted as being resolution-independent pixels and are scaled according to the DPI automatically.
I am just a beginner in game developing. Right now I am developing a game using Apple's Sprite kit and found out that the best way to position nodes on the scene is to provide percentages of width and height of the window boundaries as it makes sure all the nodes maintain their positions almost regardless of change in device display size. Using pixels to position nodes is not a peculiar idea as with the change in device display size of iPhone, nodes are either cut off or the scene squeezes leaving empty space around the scene boundary. I have watched how Apple recommend using scene editor but my issue is, using scene editor it allows you to position nodes by choosing pixels and not relative to to scene width or height. Am I making a mistake in understanding the scene editor capability. If I position all my nodes using scene editor as its saves a lot of time, how can I avoid problem with different iPhone sizes. I appreciate your help.
This is an age old problem, from all media formats.
You must decide, personally, what your favourite and most desirable target device is, and then make choices best for both it, and your creative process.
After making that decision you'll have to make your own decisions on how compromised you become on other devices, or how much you compromise your creative and production processes to benefit other device sizes and aspect ratios.
It's a balancing act.
And I strongly suggest favouring your favourite device and putting off all consideration of adaptation to other devices until after you've made something great.
Others will disagree.
Question : What are the uses of changing display resolution in full screen mode in GAMES and should it be allowed?
More info : The way i see it,
Privilege perspective : When you request your window manager for a window context, you also have the option via a flag usually to set the window to a fullscreen mode, In fullscreen mode, you can set the window resolution to a resolution of your choice usually from a given list, In most cases, that will change the display resolution, affecting your desktop environment, Should a program that is not your window manager have control over your display monitor?
Bugs : OS / Software depended in mind, When a program faults and trigger a crash, if the program fails to exit correctly, You may still end up with the same resolution asked by your software (also applies to gamma ramps when not using shaders).
Practices : Since the dawn of pc video games as far as i know, You always ended up having a "Native resolution" and everything just getting re-scaled to it, In today's world, You also have "Dynamic resolution scaling" methods and other tricks with frame buffer objects, Do we gain any benefit from actually changing the display resolution?
Performance wise, You can always change other settings to improve performance, Not just resolution.
Aspect ratio in mind, If your display monitor by default is using 16:9 for your desktop environment, Would you actually change it to something else? Obviously you should have the option, but should it be changed through a software that is not your window manager?
Thanks in advance, I may end up revising the question during the first few hours after posting.
Always pick nice defaults that don't change the display mode on launch. If the user wants to go to the graphics settings page and set it to 1024x768 full-screen mode though, let them - they probably know what they're doing.
As for performance, there can be reasons to use non-native full-screen. In addition to the performance benefit you get from drawing fewer pixels, you get access to fixed-function hardware that scales up the image on scan-out. If you scale up in the renderer itself, this is at least one extra full-screen read + write. If you're fill-rate bound, this can impact your framerate.
Something to consider though is that if you have any kind of post-process pass, you will usually be doing a read+write anyway, so you can do scaling at the same time effectively for free. Also, using native resolution for your final target is the only way to get crisp edges for things like text. Often, a game will use a scaled down target for 3D rendering, and merge with a native-resolution overlay.
In a nutshell:
Pick good defaults (windowed, or windowed-fullscreen native resolution).
Allow the user to set the window target resolution and mode (windowed, windowed-fullscreen, or fullscreen).
Allow the user to independently select the 3D resolution scale factor (25% - 200%).
Always draw the HUD and any text at the window target resolution.
When one looks at the Guidelines for fonts, we see that fonts are specified in points. A point is 1/72 of an inch so it is an absolute measure: a 10 points character should show at the exact same absolute size on any monitor at any resolution. That would make sense to me as I want to be able to read text -at the same size- whether on a 10 in tablet or a 23 in monitor. In other words, I want my text to be readable on a tablet, but I do not want it to be too big on a monitor.
On the other hand, I can understand that some UI elements could be specified in pixels, as in the Page layout guidelines.
However, in XAML font size is specified in pixels which is device dependent (to my understanding). Hence the fonts size will look tiny on a monitor with a higher resolution! See this post for more details. The answer in that post says "this way, you are getting a consistent font size". I can't see how I am getting a consistent size when it changes when the resolution changes?!?
Should I load different font size programmatically depending on the resolution of the device?
I see here that Windows does some scaling adjustment depending on the DPI. Will this adjustment be enough for my users to have a great experience on a tablet and on, say, a 20 inch monitor (or should I programmatically change the font size depending on the device resolution)?
Bonus question: WHY are the Font Guidelines written using points when the software tools do not use points (like, what were they thinking)?
"What were they thinking" is extensively covered in this blog post.
You'll also see described how scaling for pixel density is automatic:
For those who buy these higher pixel-density screens, we want to ensure that their apps, text, and images will look both beautiful and usable on these devices. Early on, we explored continuous scaling to the pixel density, which would maintain the size of an object in inches, but we found that most apps use bitmap images, which could look blurry when scaled up or down to an unpredictable size. Instead, Windows 8 uses predictable scale percentages to ensure that Windows will look great on these devices. There are three scale percentages in Windows 8:
100% when no scaling is applied
140% for HD tablets
180% for quad-XGA tablets
The percentages are optimized for real devices in the ecosystem. 140% and 180% may seem like odd scale percentage choices, but they make sense when you think about how this will work on real hardware.
For example, the 140% scale is optimized for 1920x1080 HD tablets, which has 140% of the baseline tablet resolution of 1366x768. These optimized scale factors maintain consistent layouts between the baseline tablet and the HD tablet, because the effective resolution is the same on the two devices. Each scale percentage was chosen to ensure that a layout that was designed for 100% 1366x768 tablets has content that is the same physical size and the same layout on 140% HD tablets or 180% quad-XGA tablets.
I just noticed an interesting thing while attempting to update my app for the new iPad Retina display, every coordinate in Interface Builder is still based on the original 1024x768 resolution.
What I mean by this is that if I have a 2048x1536 image to have it fit the entire screen on the display I need to set it's size to 1024x768 and not 2048x1536.
I am just curious is this intentional? Can I switch the coordinate system in Interface Builder to be specific for Retina? It is a little annoying since some of my graphics are not exactly 2x in either width or height from their originals. I can't seem to set 1/2 coordinate numbers such as 1.5 it can either be 1 or 2 inside of Interface Builder.
Should I just do my interface design in code at this point and forget interface builder? Keep my graphics exactly 2x in both directions? Or just live with it?
The interface on iOS is based on points, not pixels. The images HAVE to be 2x the size of the originals.
Points Versus Pixels In iOS there is a distinction between the coordinates you specify in your drawing code and the pixels of the
underlying device. When using native drawing technologies such as
Quartz, UIKit, and Core Animation, you specify coordinate values using
a logical coordinate space, which measures distances in points. This
logical coordinate system is decoupled from the device coordinate
space used by the system frameworks to manage the pixels on the
screen. The system automatically maps points in the logical coordinate
space to pixels in the device coordinate space, but this mapping is
not always one-to-one. This behavior leads to an important fact that
you should always remember:
One point does not necessarily correspond to one pixel on the screen.
The purpose of using points (and the logical coordinate system) is to
provide a consistent size of output that is device independent. The
actual size of a point is irrelevant. The goal of points is to provide
a relatively consistent scale that you can use in your code to specify
the size and position of views and rendered content. How points are
actually mapped to pixels is a detail that is handled by the system
frameworks. For example, on a device with a high-resolution screen, a
line that is one point wide may actually result in a line that is two
pixels wide on the screen. The result is that if you draw the same
content on two similar devices, with only one of them having a
high-resolution screen, the content appears to be about the same size
on both devices.
In your own drawing code, you use points most of the time, but there
are times when you might need to know how points are mapped to pixels.
For example, on a high-resolution screen, you might want to use the
extra pixels to provide extra detail in your content, or you might
simply want to adjust the position or size of content in subtle ways.
In iOS 4 and later, the UIScreen, UIView, UIImage, and CALayer classes
expose a scale factor that tells you the relationship between points
and pixels for that particular object. Before iOS 4, this scale factor
was assumed to be 1.0, but in iOS 4 and later it may be either 1.0 or
2.0, depending on the resolution of the underlying device. In the future, other scale factors may also be possible.
From http://developer.apple.com/library/ios/#documentation/2DDrawing/Conceptual/DrawingPrintingiOS/GraphicsDrawingOverview/GraphicsDrawingOverview.html
This is intentional on Apple's part, to make your code relatively independent of the actual screen resolution when positioning controls and text. However, as you've noted, it can make displaying graphics at max resolution for the device a bit more complicated.
For iPhone, the screen is always 480 x 320 points. For iPad, it's 1024 x 768. If your graphics are properly scaled for the device, the impact is not difficult to deal with in code. I'm not a graphic designer, and it's proven a bit challenging to me to have to provide multiple sets of icons, launch images, etc. to account for hi-res.
Apple has naming standards for some image types that minimize the impact on your code:
https://developer.apple.com/library/ios/#DOCUMENTATION/UserExperience/Conceptual/MobileHIG/IconsImages/IconsImages.html
That doesn't help you when you're dealing with custom graphics inline, however.