Improved appearance of images and artworks - Part 3

[ferferga]

This is my continuation of the job done in #357 and #512.

Changes
The backdrop of the "Now playing" section in dashboard now looks at a decent resolution, as well as the tiny profile pic below it:

Also, the gap between the containers and of the images has been fixed:

• Before:
  

• After:
  

The backdrop header of the mobile interface in the itemdetail page has been improved as well, rendering the full size image instead of the scaled one. Also, the profile photo in the header of every single place is rendered at full resolution:

[Bond-009]

Yes please, hate those low res images.

[dkanada]

It looks like there are conflicts with the ItemDetails page after we deminified the source files, apologies. Also, apparently Chrome can't handle your improvements to the media card images so could you roll that back and add a maxWidth parameter again?

[ferferga]

It looks like there are conflicts with the ItemDetails page after we deminified the source files, apologies. Also, apparently Chrome can't handle your improvements to the media card images so could you roll that back and add a maxWidth parameter again?

Thanks for pointing this out. When I made the changes in my branch first, I didn't notice any degradation of performance in 10.3.z (wouldn't make a PR with these). However, it seems that somewhere in the middle of the process, a Chrome update introduced these issues, as well as 10.4.1 changes. I had already most of my library images optimized with jpegoptim and optipng so I think this didn't hit me so hard, but, after reinstalling Jellyfin from scratch this week, I can confirm it is a bigger problem with unoptimized images.

The big images adds overhead for sure, but I think that there's something in the lazy loading and the portion of the code that handles gamepads (I'm still trying to understand some of the scripts that get executed) that are exhausting even more resources alongside with the images.

Test for yourself: Loading anything inside the Web UI will be super fast, even with those super high-res images. However, the lags happens as soon as you scroll or interact with something in the interface. Just check the profiling I did after scrolling just to the middle inside a loaded library:

See this profiling captured when going from the index to a library page:

Also, notice in the screenshots taken by the profiler how the page turns black when you scroll. Scripting is taking more resources than the images themselves.

In my opinion, we should really debug what's happening with the scripting instead of getting rid of the high-res images, because as @Bond-009 said, the scaled images look pretty horrible (and even worst if you are someone like me who uses this in huge screens). The full resolution images just work pretty well everywhere, as we are giving the browser of whatever device the control of the scaling, instead of forcing a fixed one (old UI cards were impossible to read in a friend's 98" TV for example). Ideally, we find a way to get the appropiate scaling retaining 100% of the fidelity for the human eye and also fix the issue with JS. However, I don't think this is that easy to do: it's completely impossible to know the perfect method to do it perfectly for all the devices out there.

I'm not a JS expert, and as I'm going to start my exams, it is impossible for me to dig deeper in this issue, so any help with this is appreciated, as I really think that this is a major improvement in the appearence that we shouldn't discard. Menawhile, revert back the changes in the "Part 2" PR yourself for fixing the issues for the users for now, as I don't have any spare time for doing this, at least this week. As soon as I have some free time, could you help me in debugging this @dkanada ?

Btw, I think that this "Part 3" PR should be going forward, as it only renders one full resolution image for playing item in the dashboard, and another one inside the details page of an item, so the overhead of it is zero.

Thanks for reading this huge chunk of text.

[JustAMan]

I feel there should indeed be a separate PR fixing Chrome lagging.

So I think after merge conflicts are resolved we can merge it.

[dkanada]

@ferferga thanks for fixing all these image problems. I think a clean interface is the largest issue with Jellyfin compared to Plex right now, so these help a lot.

[joshuaboniface]

Backported into 10.4.2 including the deminification of the relevant section of src/controllers/itemdetailpage.js.

[ferferga]

@JustAMan I already found that the source of the lag is caused by the 'gamepadtokey.js' script under /components/serverNotifications. I removed it just fine and I've been using it on all my devices without issues. Although I would like to investigate the root of it (and completely remove scripts that call it in case it's obsolote and no longer doing a useful job), I think that it would be a good idea to remove the file in 10.4.2 packages, as a quick and temporary hotfix. It's really annoying how it lags right now.

CC @joshuaboniface as well

@dkanada Thanks to you as well for approving it 😊. It's great to see that the contributions are considered to be useful for some people!