about resolution independence...

Richmond richmondmathewson at gmail.com
Fri Mar 1 15:23:26 EST 2013


On 02/28/2013 10:56 PM, Colin Holgate wrote:
> I know quite a bit about showing content at a size that is different to the original document size, everything I make in Flash uses that ability, it lets me make a single file that works for all existing mobile screens. But, it would be easy for most people to not understand what resolution independence is, or what the benefits are.
>
> What it is not: Something that will automatically layout your interface, using different styled buttons, or different arrangements of controls. If you're doing an app that needs different layout for portrait and landscape, or different buttons for small screens compared to large screens, then that's more like the current geometry manager, plus some code logic.
>
> What it is: The ability to layout your app with a given aspect ratio, and then have that layout fill a device screen of the same ratio, even though the device is a different pixel size.
>
> For example, if you want to create an app that works for all iPads in landscape, you could layout the card as a size of 640x480, and that card would fill the 1024x768 iPad 1 & 2 screens, and the 2048x1536 iPad 3 Retina screen.
>
> If you wanted to design for iPhone, but couldn't bare working at 480x320, you could work at a comfortable 960x640 and have an app that is immediately correct for iPhone 4 Retina, and would still exactly fill an iPhone 3gs screen.
>
> Now, those are the simple cases for resolution independence, there are more exceptions to the above examples than there are cases that are so convenient.
>
> Suppose you want, as an obvious case, to support the full width of the iPhone 5 screen, as well as the iPad screen. You could have 960x720 of content, which would scale to exactly fill the iPad screen, and you would accept the fact that empty areas would appear on the iPhone 4 and even more empty space on the iPhone 5.
>
> That's not ideal though, so instead you might have extra content that extends beyond the left and right of the card window. On iPad you would never see that extra content, but on the other screens you would.
>
> To achieve that the resolution independence system would need to be able to place the card centered on the device screen, currently it's always at the top left of the device screen.
>
> Another solution to the problem is to allow the wider screen device to cut into the top and bottom of the card window. In that case you would have content near the edges that was not vital, and if it didn't appear on the iPhone 5 screen it wouldn't matter.
>
> There may also be cases where you want the card to remain at 100 percent size, but be centered on the screen, whatever size it is.
>
> Here are some examples of how all that resizing and aligning might look. In each one you will see some lines. The red lines represent the iPad ratio, the green lines are iPhone, and the blue liens are iPhone 5. Incidentally, this all applies to Android too, where the narrowest Android is the same as the iPad, and the widest is the same as the iPhone 5. Open the links and do window resizing to simulate different device screens.
>
> 1. Top left alignment, and no scaling. This is identical to how LiveCode works currently. You would have to do all layout management with code. Try resizing the window and you'll see that more content is revealed to the right and bottom:
>
> http://xfiles.funnygarbage.com/~colinholgate/rev/topleftnoscale.html
>
> 2. Centered, no scaling. I can't immediately think of a good usage case for this one, other than maybe you have a backdrop image that works better when its centered:
>
> http://xfiles.funnygarbage.com/~colinholgate/rev/noscale.html
>
> 3. Show all. In this one the content is resized to fill the window, and in doing so it makes sure that all of the card window's content is visible, doing that by revealing extra content area. In this case that extra area is empty, but it need not be:
>
> http://xfiles.funnygarbage.com/~colinholgate/rev/showall.html
>
> 4. No border. Again, the content is scaled to fill the window, but this time it's at a size that makes sure you don't see any empty areas. The content will be cropped on either the left and right, or the top and bottom, depending on how narrow you make the window:
>
> http://xfiles.funnygarbage.com/~colinholgate/rev/noborder.html
>
> 5. Exact fit. Here the card window is squished to exactly match the device screen. I can't think of ANY usage case for this! But, for completeness here it is:
>
> http://xfiles.funnygarbage.com/~colinholgate/rev/exactfit.html
>
> The scale modes I use the most are Show All and No Border. But then I mainly do graphical scenes, and not control filled utility applications. If you are doing those sorts of things you could use code to do the general layout for all aspect ratios, from 4:3 through to 16:9, and then let the Centered No Scale mode or Top Left No Scale modes take care of the different pixel dimensions.
>
> Please let me know if I need to go not more detail!
>
>
>
> _

Resolution Independence is another unattainable goal rather like 100% 
cross-platform compatibility, a magnificent ideal maybe,
and not a bad thing to aim for as long as one realises that one will 
probably never attain it and does not become thoroughly
disenchanted as a result.

And this posting is excellent, but could be boiled down to something 
slightly shorter for non-technical folk:

A widescreen television is NOT just a bigger screen than the 13 incher 
my Dad bought in 1973.




More information about the Use-livecode mailing list