Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Touchscreen Responsiveness

This site may earn commission on affiliate links.
Has anyone had the opportunity to fiddle with the touchscreen at a beta event? Just curious how responsive it feels in person.

From videos online it looks a little laggy at times. Although I suppose Tesla's software engineers are doing optimizations all the time.
 
Has anyone had the opportunity to fiddle with the touchscreen at a beta event? Just curious how responsive it feels in person.

From videos online it looks a little laggy at times. Although I suppose Tesla's software engineers are doing optimizations all the time.

I had the same findings as Doug. When the beta was in Toronto I played with the touchscreen for ~5 minutes and found the UI to be responsive.
 
What videos are you referring to? Early (alpha) screens were not as fluid as todays (beta) screens...

The Forbes video, for instance: http://www.youtube.com/watch?v=G9-78a_InBA.

Look around 2:51-2:55. She taps the screen to minimize or expand a window, and there's about a 1 second delay. The map looks a little slow (although granted this is just due to 3G latency in downloading maps).

Or in this one: http://www.youtube.com/watch?v=DZaaDSKkagA

Around 1:40 when he taps buttons. Best example is in this video at 4:40 when he pinches to zoom. Looks like it's really bogged down. I understand it takes a bit to download the maps, but the interface update itself shouldn't be so laggy.
 
The Forbes video, for instance: http://www.youtube.com/watch?v=G9-78a_InBA.

Look around 2:51-2:55. She taps the screen to minimize or expand a window, and there's about a 1 second delay. The map looks a little slow (although granted this is just due to 3G latency in downloading maps).

Or in this one: http://www.youtube.com/watch?v=DZaaDSKkagA

Around 1:40 when he taps buttons. Best example is in this video at 4:40 when he pinches to zoom. Looks like it's really bogged down. I understand it takes a bit to download the maps, but the interface update itself shouldn't be so laggy.

On the one in Newport two weeks ago, I noticed zooming in on Google Maps was slower than I expected; on a Mac, if you zoom in, it instantly zooms what's already on the screen (making it somewhat fuzzy) then fills in the detail. There was a noticeable pause before anything happened in the Beta.
 
On the one in Newport two weeks ago, I noticed zooming in on Google Maps was slower than I expected; on a Mac, if you zoom in, it instantly zooms what's already on the screen (making it somewhat fuzzy) then fills in the detail. There was a noticeable pause before anything happened in the Beta.

That's probably due to the speed of the 3G connection, not the processor.
 
Then I hope they optimize it to act more like Google maps on an iPad. It's responsive in scrolling and zooming, even when it hasn't yet downloaded the new map detail. The second video I posted @4:40 looks painfully sluggish.
There's different approaches to this. I know iOS (since the first version) "cheats" by allowing the zoom even though the rest of the data hasn't downloaded yet (I think the browser handles zooming the same way). It certainly makes things feel more responsive. Others pause and wait for the download before proceeding.
 
There's different approaches to this. I know iOS (since the first version) "cheats" by allowing the zoom even though the rest of the data hasn't downloaded yet (I think the browser handles zooming the same way). It certainly makes things feel more responsive. Others pause and wait for the download before proceeding.

You should always go for user experience. I'd rather wait for the map image to clarify than to see a delayed reaction after I press a button
 
If you don't give a visual or audio response within half second, you're frozen and the user will start hating on you. If you don't show something within 1/10th of a second, you're slow - if you can't actually do something by the time 1/10th of a second passes, you have to at least show a wait cursor. If it's interactive (e.g., dragging or pinch zooming), you can't be more than two ticks (1/30th of a second) behind. Successive refinement at idle time is just about always the right answer.

User events must be treated as real-time interrupts, and all the heavy lifting has to happen at idle time or on a background thread or in another process.
 
There are a LOT of things that can affect the touch screen responsiveness. On hardware side the NVIDIA Tegra processor should be up to the job, although we don't know which model or what clock speed will be used. The amount and type of RAM that is used can dramatically affect performance. We also have no idea what the touch screen controller is, or what the touch panel is. It looked capacitive from the way it was being touched and responding which makes it nicer to use (but hard/impossible to use with gloves on).
On the software side there are tons of variables to tweak, there is the OS, which I understand it Linux based, the power consumption optimization settings for the touch controller including its sleep settings, is the processor being put to sleep? (as in your cell phone is). As others have mentioned the maps may not be stored locally so downloading adds delay dependent on where you are and the cell network loading. It would be nice if the put a few GB of extra NAND memory in the car and had all the maps stored on the car, (not sure that google offer that though?) as I assume after 3 years or so we will be picking up the cars cell phone data plan bill?
 
That's probably due to the speed of the 3G connection, not the processor.

No, perhaps I wasn't clear enough. My point was that the computer responds instantly to the zooming, and only then fills in the missing detail from the 3G connection. It didn't respond to the zooming for quite a noticeable time. Even the employee doing the demo seemed surprised by its action.
 
With the Google Maps API it would be really easy to pre-cache plenty of map area (the current Android app already pre-caches a bunch). Also, unlike a phone, it's a car, and it's really easy to predict what would need to be pre-fetched, and since Maps went to a vector format, it's pretty compact. You're not going to be woken up all of a sudden a few thousand miles away invalidating all that cache. Even then, panning / zooming / rotating should use a primary feedback mechanism if drawing 'the real stuff' can't maintain 15fps (I'd prefer 30fps for fluid feedback). Nothing that requires a server roundtrip should ever be between user input and feedback.
 
In the Houston store it was painfully slow on loading web pages and maps, but everything else was very quick. I think one of the people said it was because the reception was really poor in there, and they didn't have wifi. (or something to that effect)