Library Brainstorming

[SentaiBrad]

bd00 said Also, people with libraries THAT big must have plenty of disk space, at least enough not to worry about an extra small thumbnail front cover.

That is true. We could also choose to resize just the front covers permanently and keep the back covers full sized? Though that's a poor solution to the problem. Oh, and I was not considering Vector images. In my mind if you are sizing and resizing constantly that is what you would go to, but by no means did I mean that is what we should use. We could try a solution of caching two sizes and displaying the smaller one. Resize the images on import, at least the front covers by 40%-75% then show those on the library view then retain the full sizes for full screen view. Edit: Unless there is a way to make the system use less resources when you make the images smaller as is. I would say only cache what the user can see if its possible to make it a variable the program can detect then add 2-3 rows. That way when its resized to smaller you can still try and cache the same amount. More images, but a lot smaller. I assume that as of right now the caching that does take place is for the entire front and back cover.

[bd00]

I think what you are saying is exactly what I suggested. * Keep all original images. * Add an additional thumbnail of the front cover, just a simple resize to a standard size, no conversions. * Use the thumbnail for standard view (cached) * Use the originals when viewing full screen (only load on request) Does LB currently cache the back covers for the flip cover option? If so change this. I'm sure I suggested a while back to only cache what the user could see +change, but I think there was a reason why this couldn't be done here. It should be split into platforms really, this will solve the problem for many. Still have the option to view all games for people who prefer it, but if they have a large library they should expect some lag. But it's like that with anything really. Doing it this way, at least allows users, who don't mind having their library split into platforms, avoid the lag.

[SentaiBrad]

bd00 said I think what you are saying is exactly what I suggested. * Keep all original images. * Add an additional thumbnail of the front cover, just a simple resize to a standard size, no conversions. * Use the thumbnail for standard view (cached) * Use the originals when viewing full screen (only load on request) Does LB currently cache the back covers for the flip cover option? If so change this. I'm sure I suggested a while back to only cache what the user could see +change, but I think there was a reason why this couldn't be done here. It should be split into platforms really, this will solve the problem for many. Still have the option to view all games for people who prefer it, but if they have a large library they should expect some lag. But it's like that with anything really. Doing it this way, at least allows users, who don't mind having their library split into platforms, avoid the lag.

I agree with the Console separation but even I like to look at entire Genre's or the entire library at once. So it should still be defaulted to this obviously. I am unsure if it does cache the back cover, but it just was a blanket statement, I am unsure.

[Jason Carr]

Thanks guys for the good discussion. Some thoughts/responses I had while I was reading: Per-game XML files vs. one large XML file...in this case it's actually faster to use one file (no matter how big) vs. many. So if anything, performance would decrease if we switched to local XML files. However, I'm not against using local XML files on import, for instance, though I don't currently consider that a high priority (it does present some issues, such as keeping the local XML files up to date). As far as using an actual database instead of an XML file, believe it or not, I am using a relatively cheap database of sorts on the backend. I load the XML file up into a data set with tables and such. So saving and loading is just an import and export to and from the data set. This does mean some extra time on save and load, but that helps to allow for more portability, and allows for running LaunchBox on several different machines all at the same time without overwriting changes on any of the machines (synced via Dropbox or similar). Speaking of portability, let me explain why it's useful. On a thumb drive, no, it's not very useful. But in my situation (and it sounds like bd's as well), we keep our entire LaunchBox installations and games library inside Dropbox, so that we can sit down and play our games (with saves and all) between all the computers we own, seamlessly and without thought. I consider this an important feature (it was one of the main reasons I built LaunchBox to begin with). On using more cores...modern Windows applications written in .NET can automatically take advantage of CPU cores. It's not always the most effective or performant way to do it, but in general it does do a good job at it. More importantly, in .NET you cannot directly tell CPU cores what to do (Microsoft built it that way on purpose). Therefore, no, I can't improve performance by "using more CPU cores", unfortunately. That said, it should be doing a decent job at it already. On to images. There's no image resizing going on on-the-fly, other than the first time images are loaded. Images are then cached to RAM and to disk. The main issue I need to resolve here is to stop caching every single image in RAM, and do better in choosing between the hard drive and the RAM cache. That should solve the problem, just haven't gotten to that yet. Resizing downloaded images won't make anything any faster, because I already cache the perfectly-sized and and drawn box art (with the border and such) to disk and RAM, so there is no resizing or drawing going on except for when you resize or replace the box art. Also, the only images which are a problem RAM-wise and performance-wise are the box art images. Fan art, etc. is loaded from disk only when needed. Since there's only one of them at a time, it's not an issue. Only box art is cached in RAM. Finally, only the currently shown front/back box art is cached into RAM. If the back is displayed, the back is cached. If the front is displayed, the front is cached. So unfortunately I can't cut the RAM usage in half that way, as I'm doing that well already. I think that about sums it up. Thanks again guys. Hoping to put out another beta this weekend.

[bd00]

Ah OK, I didn't realize you were doing that, I got the impression full sized box art were being cached. Also, if a user starts with a filter, does LB only cache the filtered content?

[Jason Carr]

Hmm, good question. I believe LaunchBox starts with the visible games and caches them, and then moves on to the invisible games in the background and caches those as well. But I do need to revisit that code (I don't exactly remember the specifics).