Kodi Community Forum

Full Version: Skin scaling for different resolutions
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Hi guys,

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!

Cheers,
Jonathan
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 -

PHP Code:
<control type="topgroup">
...
</
control>

<
control type="centergroup">
...
</
control>

<
control type="bottomgroup">
...
</
control
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.

Cheers,
Jonathan
The problem I see with it is there is a reason most graphically intensive web pages have fixed width Smile its very hard to make these things dynamic when your using fixed sized images
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.
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.
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.
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
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.
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"?

Cheers,
Jonathan
jmarshall Wrote: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"?

How could we test that? E.g It looks good on my iPad, but I can't troubleshoot on Android because I don't have one. I could only hope for the best.

How about nice and simple, down-to-Earth, Foundation-like skin made for iPad as starters. Later, it could be very easily manually fine tuned for a specific Android tablet or anything.
You can test it real simple using different window sizes on your computer. It all comes down to "does it look good in 4:3 as well as 16:9".

Actual device does not matter at all - XBMC will take care of displaying your skin the same way across all devices that have the same aspect ratio.

Cheers,
Jonathan
It might have been discussed in the past but with this idea of introducing resolution-independent skins perhaps now would be a great time to perhaps introduce, however limited at first, resolution-independent vector images.

While anti-aliasing png images are great for where XBMC is now, they are definitely limited in what resolution they can be used at before they begin to look less than perfect. The largest size, where the image displayed is exactly what the skinner had envisioned, is always going to be the size they were originally created in.

Taking Jonathan's idea of separating the screen into 3 distinct areas is going to be a challenge for skinner to create png images that are going to look good at 1024 and at 1920. There's stretching that needs to be taken into account. Or is stretching is not used, but that only works for repetitive patterns (simple gradients, carbon mesh, etc).

Using a vector image will allow the skinner to be confident that any resolution, the image will be displayed with the same quality.

From a coding point of view, would skinners be required to include these differing positions based on landscape / portrait or is that something that XBMC would be able to intelligently determine based on a single given resolution set?
Please keep the thread on topic - I have no desire to add vector based graphics at this point. I welcome a patch for it, and am more than happy to advise/comment etc. as required.

Cheers,
Jonathan
How do you like the idea of percentages in the sizes and dimensions.

A problem that i found is, if i set an background image to scale and another above that to stretch, they looks displaced if i change from as example from 16:9 to 16:1= aspectratio. Maybe it should be exist instructions what to look for, that the skin is usable in different aspectratios.
Pages: 1 2