Posts: 2,087
Joined: Jun 2007
Reputation:
92
djh_
Aeon Project Founder
Posts: 2,087
The burning issue for me, at least, and anyone soon to be using Aeon with 1080p poster art. We all know that thumbnail loading screws with skin animation to differing degrees depending on how big the thumbnails are. With 1080p thumbnails, though, it's crippling to every view. The only "solution" I've found has been to introduce two different "rendering types", one using largeimages and the other normal ones. So you can choose between crap animation but instant display, or perfect animation but shitloads of pop-in. Neither is particularly pleasant.
With the perfect solution being HD thumbnails that display quickly without disrupting skin animation, I'm not sure whether to ask when or if. Could additional hardware resources be used to achieve this, or is it simply unrealistic? A shame if so, because HD thumbnails are surely the way forward...
Posts: 26,215
Joined: Oct 2003
Reputation:
187
It's unrealistic to be able to load (multiple) 1080p images from disk instantaneously.
What is realistic is background loading them (and crossfading if necessary).
Posts: 2,087
Joined: Jun 2007
Reputation:
92
djh_
Aeon Project Founder
Posts: 2,087
When I said 1080p I meant 1080px in the vertical, which I appreciate probably poses the same problem. How good a solution could background loading provide? Better than the existing largeimage method?
Posts: 26,215
Joined: Oct 2003
Reputation:
187
It's identical to the existing largeimage method, with the added advantage that, when changing images due to infolabel changes, it's not an abrupt cut, rather a fade.
Posts: 2,087
Joined: Jun 2007
Reputation:
92
djh_
Aeon Project Founder
Posts: 2,087
2009-02-11, 07:38
(This post was last modified: 2009-02-11, 07:53 by djh_.)
Given that I'm only using 1080p thumbnails for fullscreen info views, would there be a possible solution in having separate big and small thumbnails for each listitem? So you could set the thumbnail cache at something more reasonable but then invoke the full size version under specific circumstances? In fact, is that already possible using some string-related magic?
UPDATE: Why yes, it is. I set the fullscreen version to:
<texture>$INFO[listitem.filenameandpath]-big.png</texture>
Bit cumbersome and there's a slight pause as it's a largeimage, but it's a neat workaround. Might there be any way of getting this properly integrated into XBMC, so you could specify something like [listitem.bigthumb]? You can have a similar naming convention to the fanart, maybe, with a -big suffix before the file extension...
