20" Panoramic: SO so slow!
fogled@mizzou
Posts: 549
I've recently installed my first 20" panoramic G5 touchpanel, and I'm really disappointed in how slow it is. Just a simple "Show popup" button takes 3-4 seconds from the moment you touch the button, to when the popup actually appears. One of my 'frantic' users is going off the deep end about it, and it's slow enough to annoy the crap out of me, too.
Are these things really just that slow? Is there anything that can be done to speed it up?
0
Comments
Hey!
What's your method for showing the popup - is it in code or in the TP5 file?
What's your show animation speed and starting position? Is it possible the starting position is way off the screen?
Z
It's in the TP5 file, not talking to the controller in this instance. It's just a standard "Show Popup" command, there are no animation, duration, or starting position parameters defined for it. It's not just that one button; all my "show popup" definitions are slow, although the specific instance I cited is the biggest most complex popup, with 16 volume bargraphs in it, and it's definitely the slowest. But the overall slowness of the panel is the first thing I really noticed about it.
What version of firmware are you using?
Button-coded page flips have always taken far longer than code-driven page calls. That goes for G4 as well. I have little G5 experience to compare, but if you want speed, drive with code. This isn't a pronto you are dealing with here...
BTW, button-driven page flips are even slow in TPControl.
Any idea why that would be the case? The code isn't helping the page render faster or anything. I would think that both options for page flips would be almost the same: Ask the panel to display the page, after that the panel has to do all the hard work anyway.
I do have several code-driven page flips which seem to be reasonably speedy, but all of them are actually full page flips, not popup calls. I'll try changing the popup to code driven and see if that helps. I could probably turn the popup to a full page flip too, see if that changes the speed.
It seems very counterintuitive that a panel design driven popup call would be slower than a code-driven PPN, but it wouldn't be the only counterintuitive thing about AMX product functionality.
I have no idea why, only years of observation of the effect. I could GUESS that they might be delayed in order to defer first actions to code calls. Another theory might be that the delay is intended to permit any RELEASES on HELD buttons to execute on the current page before whisking out from under your finger, leaving potential actions hung. There is system protection for such things on code-called pages and pops. With button calls, there is no code processing to save you.
Or it's just an unintended design consequence of how the internal resource database is managed in panels. Whatever It is, however, it's true and demonstrable.
Full page calls by button are as slow as pops.
It might code related commands are executed immediately because there’s no question as to intent whereas touch screen buttons do funky processing to determine if it was a push, a slide and accidental brush, etc before it decides the push was legitimate.
Maybe... although the slowness existed in G4 long before they attempted to simulate gestures.
And the choices for adding a page flip don't include variable actions for HOLD or GESTURE... just flip. So there's no analysis required... I really think, if there is a reason at all, it's intended to allow holds and releases to issue to the controller before the unguided flip takes the buttons away. And maybe it's even longer now, to permit gestures to complete before the page changes.
This certainly discourages programming a $10,000 panel in the manner of a pronto. Horrors.
I've only worked with 5"-10" panels before, and never really noticed any irrational slowness on them. Is the graphics processor in the 20" just underpowered for how much graphics it needs to process and display?
Absolutely not. We are talking about the marked difference in response time for showing a page via a SHOW command on a button within the panel (slow!) compared to the time to show a page called by code (fast). I see this daily in 5200 and 9000 and TPControl displays. The old CV10, CV7, CV12, CV5 didn't show it to the same degree, but it was noticeable on them as well.
I do think the delay increases with the number of pages in the project. But only the internal-called flips.
Fair enough. I have more, bigger, more complex popups in this design than in any smaller panel design, which might account for this panel seeming so much slower than a typical G4 7". Code updates are on deck for this project. Stay tuned for a report on results.
I was being generous earlier. Popup time is FIVE full seconds as a simple "Show Popup" in a Show Page Event.
I removed anything from the Events tab, implemented a PPN in code, and results are:
The simpler popup (mostly just a ~40 button matrix) renders in 2-3 seconds now, 1-2 seconds faster.
The more complex popups with all the audio sliders still takes a full 5 seconds, from when I see the command issued to the panel in the Notifications window in Netlinx Studio. It's not showing any faster.
So the slowness in this case is more complex than just whether it's code driven or not. The code drive does seem to make a difference on some of the less complex pop-ups, but doesn't make an appreciable difference on the more complex pop-ups.
I don't suppose it makes a difference if this was a supposedly natively portrait panel, but has been re-oriented in landscape mode?
I'm not familiar with the capabilities of the panel (don't know if it behaves as one big panel, or if there is something smart being done, like dividing it into more sections), but how large is that popup page? (as in pixels). Have you already tried turning it into a normal page like you mentioned?
Just curious, cause I've just converted from G4 to G5 (only option now) and used MXT-1001's, which I think were really snappy. I've never really noticed slow page flips or popup delays in any project over many years (but never used pageflips from the panel), so my first thought would be a defective panel. Isn't that an option?
OK, the internal flip isn't the whole issue here....
A quick way to find out if the images on the buttons has any effect is to make a copy of the project and DELETE the resources (images), and see if that changes things.
Yeah, I didn't end up doing the 'stripped down page' test yesterday, but my next step was to do just that: create an empty popup, get a baseline time on it, then start adding stuff to see what kind of impact the elements make. The really slow one contains about 40 volume controls, each consisting of two levels, four buttons, and a text field.
And yeah this was originally started as a G4 project, then converted to G5 when we couldn't get G4 panels but could get G5 panels from AMX.
I was also going to go ahead and call AMX tech support to see if they had any knowledge or ideas, as well.