Thank you for your donation!


Lightweight UI options
#1
Hi guys,

This is more of an idea and a failed experiment of mine rather than a request for work but I thought I'd share.

There's been a few discussions on here about the time it takes for low power devices to render the web interface. Despite having a large-ish collection this is not a big issue for me but I've seen it happen on less than ideal hardware where you have one core pinned at 100% utilization when rendering the html.
The root of this seems to be the time it takes for the client to render the album column of a large unfiltered collection when switching to and searching within the tag view. Also when rendering a very large playlist in the now playing view.

I'm thinking there's a significant portion of client-side work that could be eliminated by not including the album art in the html. My thinking being that could make rendering and displaying the tag view noticebly faster on slow hardware if that was an option.
I'm a Linux/Unix/infrastructure guy but have no experience with javascript, still I've tried hacking about. I've tried to alter/remove stuff to do with albumart in the album list by amending scripts-library.js and flushing caches on a test Pi and quickly run out of talent as the albumart remained every time.

If the UI is noticeably sped up by removing flourishes like albumart in the tag view's album list and maybe some tag info in the active playlist maybe this could be a selectable option in Moode's config, like a "Basic" or "Lightweight" UI option for those who want to use an old phone or tablet as a control surface.
Reply
#2
Haven't heard from @swizzle in quite a while. He has spent a lot of time trying to balance the conflicting requirements for the UI and has made some substantial improvements. 

As you say, the cover art is a challenge but I can't comment. My only contribution to the UI other than detecting typos has been to test his and Tim's ideas on various devices at hand---Android and iOS phones and tablets and Linux/Win10 laptop. I don't pretend to know all the ins and outs of the UI technology.

Regards,
Kent
Reply
#3
Having great Album art display in the UI and factoring the UI for old phones and tablets that are CPU, RAM and screen size challenged is a worthy goal but our project doesn't have the resources to do both so we opt for great Album art :-)

We do however try to improve efficiency of moOde code whenever we get a window of opportunity.
Reply
#4
I get that yes, I do like the covers in the album list but it is a lot of overhead for low power devices and as js is single threaded that's a lot of work for a low to mid-range mobile processor. Also I'm guessing this would be comparable to a Pi if rendering the UI locally on an attached touchscreen.
I had a proper look at this today and found that you already have the UI.tagViewCovers property in place in playerlib.js so it looks like this is waiting for an option in the UI's library settings or something, there is a comment that this has been considered.

I've compared between having UI.tagViewCovers set to true and false and it can make a big difference, not only with the loading time of the tag view but the responsiveness of finger scrolling the album list long after everything is rendered. The downside is that it currently seems to break the quickscroll letters to the right of the album column.

To test I used the slowest device I normally use to control Moode which is only a couple of years old and is still on sale, an Android tablet with a quad-core 1.4GHz CPU each test was started using the Samsung Internet browser based on Chromium after nginx was restarted and all browser data deleted, the collection is currently over 84000 tracks and mpd reports about 7900 albums.

UI.tagViewCovers = true;
Initial page load = 24 seconds
Switching back to tag view from folder view = 6 seconds
Unfiltering after selecting a genre = 14 seconds

UI.tagViewCovers = false;
Initial page load = 13 seconds
Switching back to tag view from folder view = 3 seconds
Unfiltering after selecting a genre = 4 seconds

As I said, not a huge issue for me normally as this tablet just sits there 24/7 running the moode interface and BubbleUPnP so everything is cached normally and somewhat quicker than the above tests but this seems to be a reoccurring complaint. Hope you consider adding a UI toggle as a future enhancement, if I figure it out in an acceptable way maybe I can send you a pr on github?
Reply
#5
lol, I forgot about that flag. I think it was something that @swizzle was using for testing.

I'll have to have a look at the code to see why quick search isn't working when the flag is false.
Reply
#6
After reviewing the code it turns out to be a bit of missing CSS in the output line that's preventing index search from working.

Fixed for upcoming 6.4.1 release :-)
Reply
#7
(01-12-2020, 06:43 PM)Tim Curtis Wrote: After reviewing the code it turns out to be a bit of missing CSS in the output line that's preventing index search from working.

Fixed for upcoming 6.4.1 release :-)

Thanks Tim, much appreciated.
btw the UI's been much snappier since changing UI.tagViewCovers to false, even on better client hardware.
Reply
#8
Keep in mind also the quick jump index relies on the list being alphabetically sorted, this isn’t always the case anymore.
Reply


Forum Jump: