[djh_]

Without giving too much away, the latest Aeon has support for massive movie thumbnails. So massive, in fact, that you have to set them to 1080 in advancedsettings. Surprisingly, performance under these conditions is fine - with one exception: when they're shrunk into a view like Showcase, these enormous images look slightly craggy. Is this because XBMC doesn't resample the images when shrinking? Can I assume that to do so would be prohibitively resource-heavy?

[CapnBry]

XBMC doesn't resample the images, but the GPU does. The whole huge image is uploaded to the GPU and then the texture is "minified" using a weighted linear blend of the 4 closest pixels to the texture coordinate of the output pixel.

The problem being that minifcation of a huge texture down to a small screenspace even with linear blending (as opposed to nearest-neighbor minifcation) produces results in aliasing of the resultant image. This problem is traditionally solved (along with the performance hit of using a massive amount of texture memory to color a relatively few pixels) using mipmaps, which are low resolution resampled copies of the big texture. XBMC does not generate nor does it support mipmaps from source, such as from a DXTC texture.

[Jezz_X]

Actually d4rk allready has a patch for mipmapping but wants to refine it before he goes any further because he not quite sure what exactly it mip maps lol

[CapnBry]

Oh sweet, you know what also would be awesome? A DXTC1 compressor and support for it in LargeImage. Would make 720p fanart usable on XBOX hardware and speed load times / use less video memory on all platforms. That's on my optimization wishlist.

And that concludes my thread derail!

[djh_]

Might one of the possibilities of this patch be that views involving large numbers of thumbnails become smoother? Because my coverflows are running like dogshit with these giant thumbnails.

[Gamester17]

Oh sweet, you know what also would be awesome? A DXTC1 compressor and support for it in LargeImage. Would make 720p fanart usable on XBOX hardware and speed load times / use less video memory on all platforms. That's on my optimization wishlist.

Please post a separate feature request on trac for all the items on your optimization wishlist

[jmarshall]

We have a couple of ideas for speeding up texture loading. The most obvious ones are:

1. Background it. That way at least you can move through the list quickly, though the textures won't load instantly.

2. Keep them around once loaded. Then when you scroll back through the list, they're already in memory (if not on the GPU).

3. Add crossfading to the image control when the infolabel changes - this should help out with background images in particular, such as fanart - saves lots of funny image controls just for the use of performing fades between things.

In terms of just speeding up the raw loading, then saving in a GPU-ized texture format is the best way to go. Unfortunately, these are generally rather large, when losslessly compressed, and thousands of thumbs are more and more becoming the norm. I suspect that DXTC1 style compression would probably be non-ideal for this cause - particularly if the user is wanting very high resolution images (which one presumes are of reasonably high quality).

Cheers,
Jonathan

[CapnBry]

I suspect that DXTC1 style compression would probably be non-ideal for this cause - particularly if the user is wanting very high resolution images (which one presumes are of reasonably high quality)

DXTC1 compressed images really suck when it comes to stuff with text or fixed high frequency patterns but they are glorious when it comes to HD backdrops. But don't take my word for it.

Here's a side by side comparison of a piece of fanart (JPG left, DDS right)1MB png file

The difference exists but is subtle at such high resolution


File sizes
Resolution: 1920x1080
Original JPG: 631kB
DXTC1: 980kB
GPU memory allocated
JPG Version: 8,100kB
DXTC1: 980kB

On win32 systems you can actually MapViewOfFile() to the DDS file, Lock it, then pass the pointer directly to OpenGL essentially streaming directly from disk to GPU with no file i/o, no decompression, no copying data before it goes to the GPU. I assume other platforms have similar mechanisms.

[jmarshall]

I can see the difference on that picture - it is reasonably subtle though. I suspect djh_ may not think it's quite so subtle, but he's an artist

I guess the main thing would be a DXT1 compressor so that we can cache thumbs and fanart using it (larger filesize, but should be faster loading and ability to keep them in memory). The loading side of it should be reasonably straight forward I should think (just dump to memory and upload to GPU pretty much).

Cheers,
Jonathan

[CapnBry]

I can see the difference on that picture - it is reasonably subtle though. I suspect djh_ may not think it's quite so subtle, but he's an artist

Hehe I can too, but I have to actually look for it. I haven't tried it on the big screen to see how bad it is either. But if you compare it to a 640x384 jpeg (which has the same gpu memory footprint) it is a clear win. It might not be for the most discriminating eyes, but when it is just a background and the load time is notably faster I think the average user wouldn't notice the quality difference.

Was just a thought, but it really can shine on platforms like the XBOX or Atom.

[jmarshall]

Agreed completely - certainly something to be looked at for fanart at least.

[topfs2]

Actually d4rk allready has a patch for mipmapping but wants to refine it before he goes any further because he not quite sure what exactly it mip maps lol

Just for discussions sake? does this matter significantly seeing as if mipmaps are created by gluBuildMipmap2D the lower res mipmaps are created using linear calculation afaik, Not saying mipmaps arent great but to be used for just loading seriously big textures to scale down it might not be the best course to use glu for it.

[topfs2]

Hehe I can too, but I have to actually look for it. I haven't tried it on the big screen to see how bad it is either. But if you compare it to a 640x384 jpeg (which has the same gpu memory footprint) it is a clear win. It might not be for the most discriminating eyes, but when it is just a background and the load time is notably faster I think the average user wouldn't notice the quality difference.

Was just a thought, but it really can shine on platforms like the XBOX or Atom.

Definatly something we should have, would be wonders for MID´s aswell. advancedsettings and default to it on ./configure --enable-mid !

[jmarshall]

Mipmapping gives a significant improvement in image quality, as the downsample by factor of 2 (multiple times) creates much clearer images than downsample to random width does, as it successfully captures all detail at the lower scale (which a linear blend from more than 2 times reduction cannot possibly do

[topfs2]

I think you missunderstood me, I never said mipmapping is bad, infact it´s great and we could definatly benifit from it. I was saying that we shouldn´t build them with gluBuild2DMipmaps as it´s not the best quality wise to use, its fast though.

I read it wrongly though as gluBuild2DMipmaps uses boxfilter, and there are better ways of dealing with this aren´t there? ie BicubicFiltering to create the mipmap levels?

Here´s a shot I made from another OpenGL project Im working on,
the texture on left is trillinear filtering with anistropic filtering at 16, the one on right is linear filtering.

I use gluBuild2DMipmaps but I´ve read there are better ways of creating them high quality. Still just using gluBuild2DMipmaps is way better than nothing, was merely for discussion.

EDIT: Oops, the images are reversed, the one on left is linear and the one on right is mipmaped, and my lod bias is abit off thats why its so blurry.. in other words, ignore me