2009-10-06, 13:04
obviously we won't be requiring a cron job if this goes golden! but currently, it does not convert them.
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.
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.
davilla Wrote:"700 mo" / "5 Go", very strange units you are using
Quote:a small Mo is a moment in time.... a gigaMo is 'quite a while'
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...
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?
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.
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).
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.
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!
Quote:Oh, and as spiff says: This is a test. That is all. Obviously the caching stuff will be done automatically in the future!
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