+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Help and Support (/forumdisplay.php?fid=33)
+--- Forum: XBMC General Help and Support (/forumdisplay.php?fid=111)
+--- Thread: Compressed textures for FanArt - testing here with XBMC 2009-10-05 (r23431) or newer (/showthread.php?tid=59115)
Compressed textures for FanArt - testing here with XBMC 2009-10-05 (r23431) or newer - jmarshall - 2009-10-05 03:15
Hi all,
Those following the SVN logs will have noticed that we now support compressed DXT1, 3 and 5 textures in the skin engine. This opens the door for the possibility of storing fanart and thumbnails in these compressed formats rather than in JPG.
The main advantage here is memory usage and loading time. DXT1 is a 1:8 compression ratio (4 bits per pixel) in terms of the amount of data kept in GPU memory, as the GPU decodes the image as it's rendering it. Thus, no CPU decode is needed at all, compared with JPG which needs CPU decode, then a full 32 bits per pixel texture. For a 1080p backdrop, this is 8MB versus 1MB - a large saving. It means more textures can be kept in memory longer further reducing load time.
The disadvantage is quality: DXT1 may not be as good as JPG, and some images may suffer from this more than others. This is what this thread is for - determining whether or not the quality degradation is:
1. Noticeable.
2. Acceptable.
To do this, I've added support for loading .dds versions of fanart in SVN via the <useddsfanart> advancedsettings.xml tag. You need SVN r23421 or higher for this
Code:
<advancedsettings>
<useddsfanart>true</useddsfanart>
</advancedsettings>Secondly, you need your fanart converted to .dds. If you're on windows, you can use the batch file and script in the attached .zip file. Simply place the MakeDDS.exe and Convert.bat script in your fanart folders (UserData/Thumbnails/Video/Fanart and UserData/Thumbnails/Music/Fanart) and run the convert.bat batch file. with convert.bat *.tbn It'll take a few seconds and 1-2MB per image. NOTE: You'll need the SDL libraries (SDL.dll, SDL_image.dll) in your path - you can place them in windows/system32 or next to MakeDDS. Grab them from the SDL website if you don't have them.
If you're on linux or OS X you'll have to wait someone to do you up a build - the source code is in tools/TexturePacker in SVN.
If you have a good eye for detail, please give it a go and see what you think. If a particular image is bad, please note down what the quality level was when it was compressed (just rerun MakeDDS on it), and perhaps post which image it is and what the quality number was.
Cheers,
Jonathan
- AnalogKid - 2009-10-05 14:11
Forgive my blissful naiveté on this... but...
Would the long term intention be to scan the source image (png, jpg etc), and cache locally in the compressed format, rather than compress the actual source images?
A double edged sword this one... since it would (in theory) be nice if local caching wasn't necessary, and the original source was used all the time. Since this still seems unfeasible, caching still has to happen, in which case, might as well take a hit during the media scanning when the images can be cached and compressed as necessary.
- spiff - 2009-10-05 14:15
the only difference as far as operation is concerned is that currently the image cache holds jpeg images, with this change it will hold dds images...
as for an explanation of dxt compression see e.g. wikipedia
- AnalogKid - 2009-10-05 14:27
Right... it was my quick reading of 'fanart folders' leading me to wonder if he meant the SOURCE folders, I should have read the brackets!
Slightly off topic / off the wall question...
For skins, would be madness to supply them with the compressed textures, but the currently focused UI element be redrawn with a lesser compressed texture?
I understand that would mean having two textures in the cache, but wouldn't it allow a faster build out of the UI, that slowly improved as the user navigated? or even reverted back to highly compressed texture when focus was lost?
Of course, a skin might be able to explicity override with thumb quality to use for critical elements.
Might be more trouble that it's worth, but it might improve stuff like coverflow scrolling etc.
- spiff - 2009-10-05 16:03
even if you could gain .1 fps by doing that, it's way way way too much code for slight-to-none gain. besides, if your coverflow has issues, your gpu is too weak. this puts more load on the gpu, not less. this is all about saving memory and cpu cycles at the expense of gpu cycles.
Image comparison... - AnalogKid - 2009-10-05 19:47
Regular JPG:
![[Image: thrillercutout1024x1024.jpg]](http://img225.imageshack.us/img225/6678/thrillercutout1024x1024.jpg)
DXT1: (with minimal jpg compression)
![[Image: dxt1.jpg]](http://img75.imageshack.us/img75/7776/dxt1.jpg)
DXT5: (with minimal jpg compression)
![[Image: dxt5.jpg]](http://img522.imageshack.us/img522/5210/dxt5.jpg)
It's very subjective... and for reasons I don't want to go into... I couldn't get the perfect comparisons... but I would say that you're hard pressed to notice any difference.... and little chance if you're +10ft from a screen.
I will try a similar comparison of a more geometric image with hard edges... but will only post the shots if there's any horrible artefacts.
I am pleasantly surprised... some sample comparisons on the web were not flattering at all!
Also, the DXT format files sizes are approx 9x that of the jpg... yes 9x LARGER. So would have to balance the disk loading speed vs time to decompress jpg, but of course, it's still less 'processing'.
NPOT issues? - AnalogKid - 2009-10-05 19:49
Are there no issues with None Power Of Two dimensions passed to the gpu? rumour has it, a good number of cards don't like texture sizes that are NPOT.
- Geeba - 2009-10-05 21:39
Not really knowing what DXT1, 3 & 5 is and that its in the general section of the forum - with sentences like "The main advantage here is memory usage and loading time" & "Thus, no CPU decode is needed at all," - at the risk of a chewing..... will this be available for or of any help to Xbox?
I know - I know! I have a Windows box but the Xbox still gets switched on first.
- spiff - 2009-10-05 21:42
xbox did this for textures for a long while. and sure, it could probably be ported to run there for fanart. not that we care
- AnalogKid - 2009-10-05 21:45
Geeba Wrote:Not really knowing what DXT1, 3 & 5 is and that its in the general section of the forum - with sentences like "The main advantage here is memory usage and loading time" & "Thus, no CPU decode is needed at all," - at the risk of a chewing..... will this be available for or of any help to Xbox?
I know - I know! I have a Windows box but the Xbox still gets switched on first.
It should do yes.
It's just a graphic format that the Graphics Processor understands and has hardware support to decompress. Meaning XBMC can toss the file at it and let the graphics chip do all the work. With JPG, XBMC has to do all the hard work :-(