After switching to JUCE 5.3.2 and testing some of my applications, I noticed that in one of my applications PNG images that were loaded from a web URL were not appearing any longer.
Saving the PNG file to the local disk and loading it from that local file does still work.
I can’t exactly pinpoint a recent specific version of JUCE where it still worked fine, but I know it still worked fine with JUCE 4.2.3 (but that’s already a while ago…)
I created a PIP to reproduce the behavior (with test files).
See the full bug report here for that:
As I only tested on Windows 10 yet, I am posting this here, but it might also happen on macOS (not sure yet).
Thanks Fabian! I can confirm this workaround works for me on Windows 10 64-bit as well.
Any idea why this stopped working (never had this fail before)?
I would prefer not to build in a hard format: I am getting these images from somewhere else, not under my control, so the type of image file may change/differ…
When I looked through the code, it appeared that it was correctly detected as being a PNG file, but only in a later step, when the actual data was loaded, things fail (at least that’s what I understood).
Of course, I could wrap this myself in some code that first tries to use the code I had first, and only if that fails, check the extension myself and do the switch based on the extension to use the appropriate image loader directly. From a user-developer I just found it very strange that JUCE can load the exact same image from a file but not if it comes from a URL.
When you ask the image format manager to look for a suitable format, it’ll try each one that it knows about, and each time it’ll try to reset the stream. So if you give it a URL stream, that’s not very good at seeking - perhaps when it tries to reset the stream to re-read it, it fails.
This might have seemed to change for you because of something trivial like the order in which it tries the formats - e.g. if in the past the PNG format was first in the list, this would have been fine. Maybe now it’s second or something?
Workarounds: simplest is to just load the whole stream into a memory block and open that. Or probably just wrapping the stream in a BufferedInputStream would give it the ability to seek enough for it to handle this.
