UI responsiveness and scaling

[Tim Curtis]

Can U provide more data (console log) that points to a bug in the software? Otherwise all we have is "it doesn't work"

[swizzle]

I don’t see anything in the 6.4 change log that would make a difference. If someone has an image and can verify the regression it’d be helpful to get a copy so I can try to find out what’s going on..

As I mentioned earlier my library is “only” ~25k tracks so I added a bunch of duplicates in the library routine that creates the album lists. With 5x additional entries (approximately equivalent to 150k tracks worth but there may be additional additional slowness with more actual tracks due to memory pressure) it takes about 1.5 seconds with the newer code base to go to the album covers view, the tag view minus album covers is basically instant. This is with my iPhone XS Max so its showing fewer album covers on-screen but my iPad Pro isn’t much slower. I only use Chrome in developer mode to access moode on my MBP, it’s slower than that but it’s not really a fair fight.

[swizzle]

I've done a bit of testing on this with a modification of the library routine that constructs the list so that it multiplies my library 10x (so it appears to moode to be the equivalent of ~250k files, or 24k albums... my earlier test above duplicated the albums sequentially so it let moode kind of cheat by caching cover images which a normal library wouldn't allow). I've made some changes that are beyond the scope of a forum post that deal more with processor use at idle and will hopefully make it into moode proper but in the meantime this will help with switching to cover view library mode. On my normal library this isn't that noticeable but...

1) the biggest thing you can do to improve moode responsiveness in general is to make sure your alpha blend value is set to 1 as that saves a lot of work that'd have to be done by your device in compositing different layers.

2) next, in panels.css look for this line:

#albumcovers .lib-entry img, .database-radio img {width:90%;max-height:calc(18vw * .9);margin:.5em 0;box-shadow:0px 0px 10px rgba(0,0,0,0.2);border-radius:.125em;}

and change it to:

#albumcovers .lib-entry img, .database-radio img {width:90%;max-height:calc(18vw * .9);margin:.5em 0;/*box-shadow:0px 0px 10px rgba(0,0,0,0.2);*/border-radius:.125em;}

This removes the drop shadow from the album art.

3) then look for this line:

.cover-menu {position:absolute;float:right;;height:5rem;width:5rem;background-size:2rem 2rem;background-repeat:no-repeat;background-position:.75rem 2.2rem;transform:translate(12%, -105%);background-image:url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><circle cx="21" cy="21" r="20" style="fill:%23ddd" opacity=".6"/><circle cx="11.5" cy="21" r="3" style="fill:%23333"/><circle cx="30.5" cy="21" r="3" style="fill:%23333"/><circle cx="21" cy="21" r="3" style="fill:%23333"/></svg>')}

and change it to:

.cover-menu {position:absolute;height:5rem;width:5rem;background-size:2rem 2rem;background-repeat:no-repeat;background-position:.75rem 2.2rem;transform:translate(12%, -105%);/*background-image:url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><circle cx="21" cy="21" r="20" style="fill:%23ddd" opacity=".6"/><circle cx="11.5" cy="21" r="3" style="fill:%23333"/><circle cx="30.5" cy="21" r="3" style="fill:%23333"/><circle cx="21" cy="21" r="3" style="fill:%23333"/></svg>');*/}

This removes the 3 dot image but leaves the ability to tap/click the bottom left corner to bring up the menu. We could alternately bind the menu to the text under the album which would eliminate a relatively complex object in favor of a simple one so is a bit faster yet but it's probably better to keep the image by default as that's a pretty universally understood metaphor for bringing up a menu and not everyone has a giant library that'd benefit as much from removing it. The menu icon is supposed to only show on mouse-over on non-touch systems though so I'm not sure how much impact that has on desktop.

Lastly while Firefox doesn't support some css features that Chrome and Safari do a quick test suggests it's the current desktop speed champ for the webui with a large library.