2012-10-23, 19:49
(2012-10-23, 19:14)MilhouseVH Wrote: The Thumbnails view is two rows of 5 thumbnails each, with fanart behind for the currently selected movie. Most of my fanart is 1920x1080, and thumbnails 1000x1500.Okay. So xbmc will have 10 thumbails in memory for current display, and possible the next row of 5 (and possible prev row of 5) ready for scrolling.
Obviously if you have 5 thumbnails across a 1280x720 GUI buffer, there's no point them being wider than 256 pixels, so that's one possible fix.
So, the 5.9M texture is probably a 1000x1500 progressive jpeg that didn't get clamped.
the 8.0M texture is probably a 1920x1080 progressive jpeg that didn't get clamped.
1000x1500 thumbnails should get clamped to 480x720 or about 1.5M, but we're not seeing that, so something else is happening.
(2012-10-23, 19:14)MilhouseVH Wrote: <fanartheight>540</fanartheight>I have a feeling these aren't being respected. That's worth looking into. Possibly they are only acted on when storoing images to Textures*db. Perhaps we need to apply those limits on initial decode.
<thumbsize>256</thumbsize>
(2012-10-23, 19:14)MilhouseVH Wrote: gpu_mem=384 is a huge improvement! I made it through the entire library with only two or three errors. And it was fast!
Not resource errors, which is surely a good sign - might just be weird images it had trouble decoding (not sure which ones, though).
And here is the vcdbg reloc, having finished caching 376 items and returned to the main menu (5 "Recently added movies" thumbnails visible, plus the "bubbles" background image): [url=http://pastebin.com
We've actually got more than 256M free so at this point we'd be okay on a 256M board, but I'm sure the memory use was higher earlier on.
Okay, there's evidence that there isn't a texture leak - just xbmc (with your settings) is trying to hold onto too many textures at once.
After you've produced a successful Texture*db cache with the 384M GPU split, is browsing reliable after rebooting with 128M?
