Album Art Display Resolution Issue

[MourningStar]

I have my album art window occupy damn near fullscreen. Therefore, most 600x600 art is too lo-res for my +27" screen (with intent to get a larger one) and, unless there is no other size available (rare), I use 1000x1000 minimum and occasionaly have both front & rear combined images. All my art is embedded with MP3tag app.

HOWEVER, today as I was preparing the screen captures I noticed a serious issue. Not sure if it's me or WACUP. WACUP has very poor resolution displayed and is quite inferior to the actual image file. As a test I opened Winamp on the same folder for comparison. Winamp does not have this flaw. Original art images are 2000x983. Thoughts?

-thx

[dro]

Winamp does not have this flaw. ... Thoughts?

I have many thoughts. This however is due to the specific plug-in limiting the requested image for it to render to be 600x600 as part of balancing out image loading times vs memory usage vs most use cases not having the window sized so large. Under Winamp, the older version of the plug-in & the Winamp core & the api that it offers has no means of doing this which is why you get the image whatever the size with the downsides of that.

An opt-in option to not scale down the requested image is what would be needed.

-dro

[MourningStar]

Under Winamp, the older version of the plug-in & the Winamp core & the api that it offers has no means of doing this which is why you get the image whatever the size with the downsides of that.

hmmm, in the mega-years I've used Winamp, never encountered a single downside. And in this instance it's an upside, imho.

An opt-in option to not scale down the requested image is what would be needed.

any chance that this need will appear soon?

[dro]

Alas your use case doesn't relate to what can be experienced by others & providing something that better balances the needs for cases of loading multiple instances of the same piece of artwork (e.g. under the Bento based skins) or the taskbar preview & a few other things.

It's all about trying to find a balance between what is acceptable vs impacting things negatively. It's also why there's the artwork cache (despite the issue you're recently having with it) as reading + resizing an image once is better than each request doing that when the artwork is being seen in a typically smaller form than it started out as. Especially with artwork sizes increasing & that having a negative impact on loading times (e.g. I had a podcast that used a 12500x12500 image & even with the caching & a few other changes added a noticeable multi-second delay).

Also just because Winamp did it one way doesn't necessarily mean what it did was right nor ideal & the same definitely goes for anything I'm doing as part of remaking it & trying to find what works or doesn't within the confines of more modern usage than what was needed in the mid-late 2000s (when an artwork api was first added to Winamp).

Hopefully I'll remember to get it done for the next build that I'm trying to get completed.

-dro

[MourningStar]

Hopefully I'll remember to get it done for the next build that I'm trying to get completed.

best of luck, and thanks!

[dro]

Rather than adding a specific config option & having to remember to turn it on & all of that, it'll instead determine what to do based on the current window size.

So if you've got a larger sized window then it'll just ask for the original artwork instead of the up to 600x600 limited version which for how you're doing things (& others I assume) makes sense to resize that than resizing an already resized image.

Have also applied the same change to the lyrics plug-in (which is using a common code base) so that should cover that for those users as well.

-dro

[MourningStar]