Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Moving the artwork file decoder to its own thread (Read 7178 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Moving the artwork file decoder to its own thread

It currently seems as if the album artwork file decoder is running in the same thread as the UI, causing the UI to stop updating till the album art has been finished processing. The result of this is that for very large files the whole process can take up to a few seconds which hinders usability in certain cases, such as traversing a large library.

Example image: http://i1.sndcdn.com/artworks-000036491530...23-original.jpg

With that in mind, has there been any consideration of moving the decoders to their own thread or am I just not understanding the situation correctly?

Moving the artwork file decoder to its own thread

Reply #1
Any thoughts on this? Would love to be surprised by 1.2.10.

 

Moving the artwork file decoder to its own thread

Reply #2
In the mean time you can try reduce the size of the album art.
Windows 10 Pro x64 // foobar2000 1.3.10

Moving the artwork file decoder to its own thread

Reply #3
are you having this problem with the default UI artwork panel or is it some other 3rd party component you're using to view it?

Moving the artwork file decoder to its own thread

Reply #4
Default UI artwork panel naturally.

Moving the artwork file decoder to its own thread

Reply #5
In the mean time you can try reduce the size of the album art.



I think having by default a 2400x2400 album art image size is overboard. You'll not benefit with anything beyond 800x800 even using fb2k fullscreen with a large monitor resolution.

Consider this: 30" monitors normally do 2536px wide. Consider resizing your art as suggested.

Moving the artwork file decoder to its own thread

Reply #6
BTW, this image is saved as progressive JPEG. Mozilla and IrfanView open progressive JPEGs slower than normal ones, and this may be true for fb2k too.

Moving the artwork file decoder to its own thread

Reply #7
BTW, 600x600 is enough for any embedded album art viewer in any media player. Especially if compression level is very low/image quality is set to very high.

Re: Moving the artwork file decoder to its own thread

Reply #8
Now that high-res cover art is becoming more and more commonplace (I have some ranging from 5000x5000 to 10000x10000), the thread that decodes the JPEG blocks pretty much every interaction with the foobar2000 UI until decoding is complete, which can take up to several seconds.

Realistically, the decoding should be done on a separate thread that can be cancelled if the UI is changed such that the image is no longer being displayed.


Re: Moving the artwork file decoder to its own thread

Reply #10
In the mean time you can try reduce the size of the album art.

I'd rather not, That's a destructive operation and reduces the quality when displayed 1:1, or as close to 1:1 as possible on a 3180x2160.

That's akin to telling someone who archives lossless music to stop using FLAC and use MP3 because it uses less space.

Re: Moving the artwork file decoder to its own thread

Reply #11
Make a smaller copy of the album art, saved at high quality without color subsampling, and keep the large image under another name. Then you can always make a different size at a later time, or examine the art in detail. I think it is not a good idea to automatically load large images. Other players may handle them even worse, using memory for the entire uncompressed image, or refuse to load them. Large modern web covers also tends not to have much detail on them (flat design...).

Re: Moving the artwork file decoder to its own thread

Reply #12
Thanks Peter, the changes in 1.5 beta 7 make the UI usable again now that decoding/resizing is asynchronous.

Re: Moving the artwork file decoder to its own thread

Reply #13
Just for reference, it was high quality resizing to fit viewer window that was slow, decoding alone was reasonably fast, even with rather huge images. Certainly it got worse with modern high DPI displays, screen densities were lower when this code was originally written, 1920x1200 96DPI was about the largest that was in circulation.
Microsoft Windows: We can't script here, this is bat country.