View Issue Details

IDProjectCategoryView StatusLast Update
0003375AniDB WebsiteBug Report - Interfacepublic2019-08-19 00:16
ReporterBelove Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0003375: On high PPI/DPI display devices/settings, image resources are rendered at lower than display resolution
DescriptionOn high PPI/DPI display devices/settings, image resources are rendered at lower than display resolution.
The issue is most glaring in the case of thumbnail display.

I would think with the current state of tech we could make due with maybe 3 versions of each image for a significantly improved UI experience, and even for starters just modifying the logic used to choose between the two resolutions we already maintain (full resolution and the low resolution currently always used for thumbnails).

So, the simplest improvement to start with world be to use the full resolution version for thumbnails on displays with a pixel density sufficiently higher than 96 (120? 144? more?).

If you create some intermediate image resolutions you can strike a better balance for moderating bandwidth usage/page load times.

It would be nice to have higher resolution for large image display too, not just thumbnails, but that obviously would not be effective until such images are uploaded to AniDB. These would also be useful even at low-DPI for very large display layouts. However, upgrading the resolution of large images is less important because they already contain a reasonable amount of detail. They would look better with more, but thumbnails displayed to users on high PPI and/or large displays currently look bad since they have very little detail.

Among the most common high PPI displays are modern smartphones with around 500-600 PPI last I checked. Those devices might falsify their PPI as bring lower than that though; my 518 PPI 0000014:0000006.3" device seems to report about 337 PPI in Chromium-based browsers and about 339 PPI in Firefox using default display scaling settings. I assume this is because the device manufacturers feel that the 337ish PPI resolution is a good balance of quality/bandwidth for web browsing. These numbers can change based on system settings on my Android. There are display scaling settings similar to those on desktop OSs. Still, the browser reports different and lower numbers than native apps detect.
Steps To ReproduceLook at a thumbnail on a high PPI display and display setting to see the issue clearly.
Additional InformationCSS PPI detection example using media queries: https://home.heeere.com/tech-ppi-aware-css-media-query.html
Javascript PPI detection example (binary trial and error hones in on it quickly): https://jsfiddle.net/pgLo6273/2/


On my device, the two demos give slightly differing results, as do different rendering engines. Not sure if the difference between CSS and JS demos is a bug or not. I am not the author of the demos.
On my 0000205:0000518 PPI mobile device:
CSS: Chromium: 336 PPI; Firefox: 338 PPI
JS: Chromium: 337 PPI; Firefox: 339 PPI

Again, the simplest way to improve things in re. this issue to start with might be to just use the full resolution version of images for thumbnails on displays with a pixel density over some threshold, such as 120 or 144 PPI (25% or 50% greater than 96 respectively). In the long run, maintaining a wider range of resolutions would be better.

Excess resolution, if it occurs, is actually nice on small displays where users frequently zoom in and out, though could be an issue for those on limited or heavily metered bandwidth. A low(er)-bandwidth layout option could be made an option to mediate this issue (which could for now, for example, maintain the existing behavior). Users already can mediate bandwidth usage by limiting the number of items per page in result tables. There is a web design trend toward only sending data as needed in a more dynamic way these days: "infinite scroll" (though not everyone is a fan).
TagsCSS, javascript, picture, UI

Activities

There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2019-08-19 00:16 Belove New Issue
2019-08-19 00:16 Belove Tag Attached: CSS
2019-08-19 00:16 Belove Tag Attached: javascript
2019-08-19 00:16 Belove Tag Attached: picture
2019-08-19 00:16 Belove Tag Attached: UI