Skin scaling for different resolutions - Printable Version
+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: Skin Development (/forumdisplay.php?fid=12)
+--- Thread: Skin scaling for different resolutions (/showthread.php?tid=94867)
Pages: 1 2
Skin scaling for different resolutions - jmarshall - 2011-02-21 05:11
With iPad and other tablets comes possibilities for presenting your skin in a variety of different aspect ratios, which makes for complications to the skin engine.
This trac ticket takes care of some of it by allowing you to specify resolutions, but I think it's solving the wrong problem (or at least isn't a complete solution to the problem).
I've been chatting with Jezz_X and he says for simple things like displaying the same skin in 16:9 or 4:3, he's happy if you display the same thing, basically just positioning differently. Simple example is with a header, middle and footer, the positions of these would change when switching between 4:3 and 16:9, but the actual heights etc. wouldn't - i.e. you'd simply end up with a larger gap between items on the screen. Similarly, for rotation on an iPad, most dialogs fit into the center of the screen, so in both orientations you're displaying the exact same thing, just positioned differently as x+y coords are swapped.
So, I'm thinking of ways to accommodate this. One idea is to have a "layout" control that works a bit like an auto-adjusting table - essentially it gives you panels (each of which is a control group) that automatically reposition themselves - so in the above example you'd have a header panel that's anchored to the top of the screen, a footer panel anchored to the bottom, and the middle content anchored to the center of the screen. Actual content inside the panels would remain unscaled - just the positions would change when switching from (say) 1280x720 to 1280x960. We could even make it so that things would scale only if they have to (eg if you make the vertical dimension too small so that the unscaled bits inside each panel would overlap).
Another idea is to allow lists to be dynamically sized in the same way - eg it might make more sense that when we know how big our middle "panel" is, we mayaswell make the list take up that space without changing the size of each item (obviously this might have implications for exactly how we work this sizing out, if you didn't want half an item to display etc.)
How to do all this I'm not exactly sure yet. What do you guys think? The goal is to make it easier for skins to take care of differing aspect ratios that will inevitably be coming out with tablets and the like. Ofcourse, you don't have to care about it necessarily, but given the number of folk with iPads and the number of Android tablets coming out, it might be something to consider!
- Hitcher - 2011-02-21 08:49
I like the sound of three separate panels and I think this would quite well with Alaska seeing as it essentially has these elements anyway (breadcrumb/time - main content - Now Playing/Media flags).
I'm assuming it'll be as simple as working out which bits go where and putting them into different group types like so -
- jmarshall - 2011-02-21 09:08
Yeah - something like that, though a bit more general than just bottom/middle/top. I think something similar to html tables or whatever the new magic for that stuff is would be the way to go.
I'm not really sure exactly how to do it as yet internally - scaling would have to be set per-group rather than per-window. Have to think of a good XML layout and play around to see what the code side will look like.
- Jezz_X - 2011-02-21 09:59
The problem I see with it is there is a reason most graphically intensive web pages have fixed width its very hard to make these things dynamic when your using fixed sized images
- pecinko - 2011-02-21 16:08
IMO, auto switching doesn't make sense. We should do it rightly for landscape mode and don't allow switching to portrait. With mobile phones it could make sense to lock portrait and allow switching only when player is active. XBMC would not be only application that's orientation-locked.
It's not about imposing restrictions but rather to do it right and be sure navigability is flawless then spending endless hours making it work either way ending with complicated (buggy) code nobody wants to improve/support.
- vinc - 2011-02-21 16:42
I opened up a topic (here) about this a couple of weeks ago, but I don't think Davilla understood wat I was trying to say.
I also believe the whole rotating ability of XBMC on iOS makes skinning too difficult and does not improve the experience of using XBMC. You should be able to lock users in orientation, be it portrait or landscape, so you can really accomodate that specific screen size and optimize the user experience of the skin. I think pencinko is right in saying that this is the only way to ensure flawless usability.
I think being able to specify resolutions as suggested in the trac ticket in the first posts solves all problems. You could develop a skin for whatever orientation, which makes it so much easier.
- Hitcher - 2011-02-21 18:07
I didn't even realise we were contemplating portrait mode but I agree that we should lock XBMC to landscape only anyway - let's face it no-one's going watch any videos in portrait.
- pecinko - 2011-02-21 19:08
Hitcher Wrote:I didn't even realise we were contemplating portrait mode but I agree that we should lock XBMC to landscape only anyway - let's face it no-one's going watch any videos in portrait.
Well, It could be that I completely misunderstood and that we are talking about one-size-fits-all i.e. auto accommodate skin to "similar" resolutions. Even if so, I think it will prove challenging:
1024x768 - 9,7in iPad
960x640 - 3,5in iPhone
1024x600 - 7in Samsung Galaxy Tab
- vinc - 2011-02-21 19:55
Hitcher Wrote:I didn't even realise we were contemplating portrait mode but I agree that we should lock XBMC to landscape only anyway - let's face it no-one's going watch any videos in portrait.Well, rotating was enabled in the second update for iOS wasn't it? Locking rotation per skin would be a good way to ensure a skin's performance. Being able to lock rotation and define a custom or specific resolution would enable device-specific, or resolution-specific skins, which is (imho) the only way to design a skin and have it deliver the best user experience possible on the specific device.
- jmarshall - 2011-02-22 00:37
Obviously portrait versus landscape can't be done automatically across the board in any sane way, however MANY things can be shared. Simple example is dialogs on a tablet. Almost all of them can quite happily render only in the middle "square" of the screen which is shared between portrait and landscape, so no need to provide a skin that independently specifies both XML files - rather, you'd just supply a common set of XML files and XBMC should automatically place them centred as you want.
The main point I'm getting at is that for aspect ratios that don't differ significantly, eg 16:9 versus 16:10 versus 4:3, a common skin that allows some things to scale and some to simply shift can improve the display of every skin across multiple devices without forcing the skin to have a bunch of repetitive code where only a couple of positions change and everything else stays the same.
So, ignore portrait versus landscape. Consider 16:9 versus 4:3 only. How can we make it so that current skins look as nice as possible without the pure stretching that goes on now - i.e. how can we best specify "scale this control" versus "leave this unscaled where possible and alter the positioning instead"?