Fixes Issue 6262: [Bug]: Error occurred while loading images #6291
Conversation
Before this commit, the updateThumbURL() method would attempt to derive a larger resolution thumbnail URL from the current thumbnail's width and height. This derived thumbnail URL would sometimes not match an actual URL. Even creating this thumbnail URL would sometimes fail when doing string manipulation. Both errors can cause issues, with the second one crashing the thread and preventing images from being loaded. This commit simply removes the call to updateThumbURL(). Images with their thumbnails now load correctly, especially with panoramic images.
…properly Before this change, the API calls to MediaWiki would request thumbnails with atleast a specific width, rather than height. These thumbnails would often be extremely low resolution on very wide images, such as panoramas. This change instead requests thumbnails with atleast a specific height. Panorama thumbnails are now at a higher resolution than before. Additionally, the height parameter is now represented as an integer which can be changed more easily.
|
✅ Generated APK variants! |
| "&prop=imageinfo|coordinates&iiprop=url|extmetadata|user&&iiurlheight=" + | ||
| THUMB_HEIGHT_PX + | ||
| "&iiextmetadatafilter=DateTime|Categories|GPSLatitude|GPSLongitude|" + | ||
| "ImageDescription|DateTimeOriginal|Artist|LicenseShortName|LicenseUrl" |
There was a problem hiding this comment.
If I understand correctly, the reasoning is that there are more very wide images (such as panorama landscapes) than very high images?
There was a problem hiding this comment.
That is correct.
The original API call would try and retrieve a thumbnail of a fixed width instead. In ImageInfo.updateThumbUrl(), if it was too short, modify the thumbnail URL to try and get a tall enough thumbnail.
Modifying the thumbnail URL would lead to errors that stop results from displaying when searching or in Explore.
This new MediaWiki call achieves the original intention of updateThumbUrl() but instead puts the work onto the MediaWiki server to respond with a thumbnail that is tall enough.
|
Vertical images like these recent ones in "Featured" seem to have low resolution. If there is anything that can be done towards this, please do not hesitate to file an issue. 🙂
|
|
I am still testing this pull request. Sometimes I am getting this popup a lot, and exploring feels very slow. Other times it is fast. 😅
|
Interesting. I just did a lot of scrolling through "Uploaded via mobile" with the Android Studio emulator and did not get that popup. I suspect that the popup may be appearing because the MediaWiki server is taking a long time to respond. I think the MediaWiki server will scale the image to the specified thumbnail dimension if it is not cached. For large images this may take a long time, especially because the queries are in batches of 10 at a time. |
|
Do not slow server responses usually result in different symptoms, not blocking the UI? Could the new strategy somehow be taking more memory or something? 🙂 |
|
You are probably right. I'll try to reproduce this new error on my physical device and also run the profiler for CPU and memory. I'll let you know what I find. |
Description (required)
Fixes #6262
What changes did you make and why?
Several small changes were made.
Removing the call to
ImageInfo.updateThumbUrl()where the attempt to get a higher resolution thumbnail via changing the thumbnail URL would sometimes crash the thread.Fixing the API call to MediaWiki to retrieve thumbnails with a minimum height, rather than width. This replaces the work intended by
ImageInfo.updateThumbUrl().Code quality improvements: Created a
THUMB_HEIGHT_PXinteger inMediaInterface.ktto allow for easy modification of the minimum thumbnail height. Also, the API call string was spread across several lines to comply with line length requirements.Tests performed (required)
To easily test this PR, go to the Explore tab, then search for "panorama". On this PR, results will load, but will have the "Error occurred while loading images" message appear on main. Also, as stated in #6262, searching "lunar" one letter at a time should show results on this PR, but fail on main.
Tested ProdDebug on Android Studio Emulator with API level 34.