+- 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)
- davilla - 2009-10-06 20:18
hotlobster Wrote:I've tested it so.
No visible speed improvement or noticeable cpu difference on a C2D 3ghz.
But a HUGE difference of size. My Thumbnails folder was around 700 mo.
Now it's a 5 Go directory.
"700 mo" / "5 Go", very strange units you are using
- AnalogKid - 2009-10-06 20:20
hotlobster Wrote:I've tested it so.
No visible speed improvement or noticeable cpu difference on a C2D 3ghz.
But a HUGE difference of size. My Thumbnails folder was around 700 mo.
Now it's a 5 Go directory.
I'd expect the slower PC's would be the ones hopeful of any speed gain (if there is any to be had), plus, I don't know if the devs are actually loading the GPU with more textures yet. Perhaps they are just passing the new format textures but not utilising the gain memory yet.
- AnalogKid - 2009-10-06 20:22
davilla Wrote:"700 mo" / "5 Go", very strange units you are using
We all work in Mo's !!!
a small Mo is a moment in time.... a gigaMo is 'quite a while'. Thus is increase in filesize is resulting in a more Mo !
- hotlobster - 2009-10-06 20:25
Quote:a small Mo is a moment in time.... a gigaMo is 'quite a while'
lol. Good one.
Meant MB, Mo are french Mega Bytes.
- AnalogKid - 2009-10-06 21:05
Build 23458 (GL and DX).
Same DDS texture issue with a rare few images. And (could be a placebo) a good speed increase in rapid coverflow scrolling. Could be a skin improvement though, since I've updated skin too.
Confirmed texture corruption with two artefacts:
a) All (bar one) of the texture corruptions behave the same way: In the GL build it's a corrupted and 2x Width image. In the DX builds it's not corrupted but 2xWidth
b) One image has some colour channel and alpha profile. It appears slightly colourised and has transparency in parts!!!! and what is TOTALLY mindblowing... is that the transparency is showing the homepage fanart STILL doing a Ken Burns effect LOL. It's very groovey, but a total waste of CPU to be doing Ken Burns on an image that cannot be seen! (this is the same in GL and DX)
- jmarshall - 2009-10-06 23:34
Thanks, I appreciate the comments (particularly the "I can see the difference, but I don't care" stuff). Some comments:
1. JUST compress your fanart directories. No way in hell it should take 3 hours - it takes about 4-5 seconds per image here, so unless you have several thousand fanart images...
2. Obviously if you convert your entire thumbnails folder (thumbs as well as fanart) size is going to increase quite a bit - some thumbs are tiny in JPG format compared to the resulting DXT. Also, note that many of the files sitting in your thumbs folder currently are not even being used by XBMC (we never clean it out). 5GB indicates 2,500 1080p images - do you really have that many?
3. It's not optimized for size on disk, but size in memory. Size on disk is a secondary consideration, and obviously something like lzo compression can assist here.
4. Anything with an alpha channel (i.e. a png) will look strange - I haven't bothered to support or detect that as yet (clearly that needs at least DXT5).
5. Any images that show corrupt I need to know full details of your GPU, plus info on how big the image is. If it corrupts in GL and DX then that indicates a broken image I suspect. I presume you tried to load the corrupt images in a DXT viewer? If it's corrupt in a DXT viewer then I'm doing something poo on the compression. If it's only corrupt within XBMC, then I'm doing something poo on setting up the texture.
6. You're not likely to see performance benefits per-se from this change, as images still only lie in memory for 2 seconds once unused. Once we bump that up, however, things change somewhat - it will reduce swapping from GPU to system memory. Obviously there's nothing we can do about scrolling through thousands of 2MB images, however!
Oh, and as spiff says: This is a test. That is all. Obviously the caching stuff will be done automatically in the future!
Cheers,
Jonathan
- AnalogKid - 2009-10-07 00:35
jmarshall Wrote:Thanks, I appreciate the comments (particularly the "I can see the difference, but I don't care" stuff). Some comments:
1. JUST compress your fanart directories. No way in hell it should take 3 hours - it takes about 4-5 seconds per image here, so unless you have several thousand fanart images...
about 1500 fanart only images all with a min 1080 some are higher, but rarely by much. Processing time between 8-20 seconds each
Quote:2. Obviously if you convert your entire thumbnails folder (thumbs as well as fanart) size is going to increase quite a bit - some thumbs are tiny in JPG format compared to the resulting DXT. Also, note that many of the files sitting in your thumbs folder currently are not even being used by XBMC (we never clean it out). 5GB indicates 2,500 1080p images - do you really have that many?
Some of us are nerds. We are scarey.
Quote:3. It's not optimized for size on disk, but size in memory. Size on disk is a secondary consideration, and obviously something like lzo compression can assist here.
Totally understood, but 8x increase in file size is a fair hit on read performance esp if running from USB or slow drive.
I did a quick compression test on the DDS and averaged about 50% (rar max compression)
Quote:4. Anything with an alpha channel (i.e. a png) will look strange - I haven't bothered to support or detect that as yet (clearly that needs at least DXT5).
No worries, I think these will be small niggles that get ironed out. The basic thing is working!
Quote:5. Any images that show corrupt I need to know full details of your GPU, plus info on how big the image is. If it corrupts in GL and DX then that indicates a broken image I suspect. I presume you tried to load the corrupt images in a DXT viewer? If it's corrupt in a DXT viewer then I'm doing something poo on the compression. If it's only corrupt within XBMC, then I'm doing something poo on setting up the texture.
Cards are both integrated GMA's 845GM and 850 / Core2 1.8s. Definitely not high end, but arguably typical of Bookshelf size HTPC's.... I've got access to NVidia's but reluctant to start screwing with other machines that have a different purpose at home!
Couldn't load in my viewer due to NPOT. I have since located a DDS plugin for Photoshop... the image is fine... so the error lies in the decode, the driver, or the card. Likely to be decode or driver I expect.... image dimensions are 2183x1281
Quote:6. You're not likely to see performance benefits per-se from this change, as images still only lie in memory for 2 seconds once unused. Once we bump that up, however, things change somewhat - it will reduce swapping from GPU to system memory. Obviously there's nothing we can do about scrolling through thousands of 2MB images, however!
Again, understood... but... you could create super textures! and combine possibly 4 at a time (if the GPU can handle large textures)... probably not worth the hassle, I'm happy with the performance on a low end HTPC.
Quote:Oh, and as spiff says: This is a test. That is all. Obviously the caching stuff will be done automatically in the future!
Need to get a handle on the encoding time for these images. Let's hope I'm not 'typical' with high volume art and slow encoding time. Can you not use the GPU to encode?
Cheers,
Jonathan[/quote]
- jmarshall - 2009-10-07 00:45
Good quality encoding takes time. Realtime compression sucks, big time. Completely unacceptable quality from my tests.
Obviously any encoding will be backgrounded - you won't notice it, and it's likely just a blip compared to the download time of information + images.
I suspect your problem is real simple: Your GPU probably has a max texture size of 2048, and you're loading images larger than that. Thus the double width and other strange problems.
Will check the code and do up a diff for you - you can build, right?
Cheers,
Jonathan
- AnalogKid - 2009-10-07 01:01
jmarshall Wrote:Good quality encoding takes time. Realtime compression sucks, big time. Completely unacceptable quality from my tests.
Obviously any encoding will be backgrounded - you won't notice it, and it's likely just a blip compared to the download time of information + images.
I suspect your problem is real simple: Your GPU probably has a max texture size of 2048, and you're loading images larger than that. Thus the double width and other strange problems.
Will check the code and do up a diff for you - you can build, right?
Cheers,
Jonathan
Nope.
My coding days are over. I only do 'architecture' now and even that's under duress cos I've forgotten how to spell C let alone code in it, and I believe Object Orientation is when you protest against cross country running ;-)
So, if the max texture is 2048 (which seems to be accurate having just done some googling) what's the proposal...
- Reduce the image size during XBMC's encoding phase? (my favourite)
- Expect end user to keep images within scope? (pffft)
- Multiple textures? (sounds like madness)
- Use existing technique for troublesome images (might not be possible to mix and match easily)
- Go for a lie down in a silent darkened room with a cool damp towel?
- jmarshall - 2009-10-07 01:08
1. Reduce image during caching and encoding. I'll specify a maximum of 2048 in either direction.
2. On load, the only options are to either downsample (slow) or just crop. I prefer the latter. Given that image caching will downsample anyway, this isn't a problem.
3. I'll look at adding said cropping into SVN.
Cheers,
Jonathan