I've noticed the speed at which E-Touch reacts to touchscreen inputs seems a little slow. Users can be seen hitting buttons multiple times in succession waiting for an input response. It seems like their must be some room for improvement here. I believe this is a software related issue.
This happens in many different places throughout E-Touch but seems most obvious when paging through Album Art. Is there a way you might be able to save into memory the the previous and next couple of Album Art pages. Possible also when on any page to always save to memory the page or two that would be displayed if the back button is hit once or twice.
Edit: Maybe a way on the back-end that if multiple inputs are made (like paging) to be able to skip to the final page and not load those in between - although it may already be this way. Just trying to think of ideas for some more speed improvements, I'm sure you thought of most of these before.
Do you use smaller covers? This helps with the page browsing on the album art.
Yes, definitely setting covers and coversmall a reasonable small sizes (let say +/-250x250, 300x300)
in all albums improved drastically my speed handling all over the options.
I run the small covers at 170 x 170 which is fine for a 12 cover view. The reason that screen has lag is loading 12 images at 1500 x 1500 takes a noticable amount of time, there might be faster ways to load the image using a better graphic library but i have not been able to improve the speed. This has been something i am always looking at but usually improving the speed anywhere in the app involves a long beta phase to check nothing else got broken. If anyone is aware of a faster way to load in JPG images rather than using a VB image box then please point me in the direction of some examples for me to look at using.
I am sure i need to use GDI+ I keep looking at it but it looks like it would take a while to get my head around it and I keep having other stuff to work on. I am going to see if i can create a seperate app to play around with GDI+ Loading and resizing to use for loading the covers. If i can pull it off then hopefully we will see a speed increase in the album browsing screen.
Yes, I am using coversmall 170x170 which does help quite a bit over what I was using early on in version 5.
Seeing that these smaller images range from 10-20kb, which is less than a 1/4 of 1 mb for a 12 cover album page. I think the delay I'm seeing is not file size issue but maybe more of a file quantity issue. I was just thinking if the jukebox loaded a couple previous and next album art pages it wouldn't make the whole thing seem a lot smoother when paging through. Having these few pages in memory queue may make the visual appearance much snappier.
Also I'm not sure how you have it programmed but it does appear if you hit page down or up multiple times on the album art main page it seems to continue to finishing loading all the page before moving to the last. So if i click it 5 times pretty fast instead of just loading the last page it loads everything in between first. Now that we have a page indicator and I know the CD I'm looking for is on page 43 and I'm sitting on 39 I tend to just hit the button 4 times fast and notice that it loads all pages in between instead of skipping to the last.
You are correct in that it will load all pages in between however putting a couple of pages either side of the current page will not help increase the speed. This is because as soon as you page forward or back it will still need to load a page into the cache. The only way to speed this up is to switch to a faster loading/decoding method like using GDI+ and as i said this will not be a five minute change over.