Community
Participate
Working Groups
Created attachment 188113 [details] RAPSlowListenerExample When using a text box with a ModifyListener attached to it the code exectuted by the Listener is delayed causing a very noticable lag even on trivial task such as performed by the attaced code. Steps to Repoduce: 1. Add new MultipleListenersExample().run(); to an IEntryPoint 2. Enter a number in the Fahrenheit text box and view the lag. It doesn't seem to matter which browser it seems just as slow in Firefox 4 as in IE
Due to client-server nature of RAP the modified text is not send to the server on every typed key, but in chunks every 500ms. This is a known limitation (introduced by design) and the lag you described is exactly 500ms + network latency.
Why couldn't this value (500ms) be configurable?? Souldn't it be up to me how much I wish to push my server. I did mark this as an enhancement, why mark it as won't fix so quickly when it provides such a bad experience to the user epecially when using a text box to do a search and trying to provide instant results in a list.
Timothy, the value of 500ms is suitable for most of the use cases. Sending requests more often leads in some cases to browser to become unstable. As RAP supports a wide range of browsers (not only the latest modern versions), we have to make sure that it behave stable in all of them.
(In reply to comment #2) > Why couldn't this value (500ms) be configurable?? Souldn't it be up to me how > much I wish to push my server. Of course it would be possible to make this value configurable. But this comes at a price: We'd need to read the config value, check it's format and range, pass it to the client, write additional tests both on client and server, document the new parameter and so on. Like Ivan, I am also not convinced that this effort is justifiable. The delay is still far below one second and I'd think this is acceptable for a web application. Is it really a problem for your application?
Hi Ralf, I do appreciate this change requires more than a little effort to implement, but I do think that it is time well spent. One of the very first things I was taught when studying GUI's is that response to the users actions is very important. It is human nature that receiving feedback after imputing something to the computer we feel as though we are in control of the process, when we don't get a response after input we feel as though the computer is in control of the process which causes a sense of unease and frustration. This is something that seems to constantly get overlooked time and time again, windows vista is an excellent example of this the initial release often left users hanging with no sign of life after preforming actions, and although the service packs did a good job of fixing this is was not enough to save the OS (admittedly there were a lot of other problem). Another great example of where companys have actually got it right is the browsers wars currently going on. Browser developers a going to great lengths to shave fractions of seconds off load/execution times and users are responding they are switching in droves. And its not just load/execution times that are being worked on it is perceived load times, where pieces of the page are displayed as fast as possible so the user perceived the page to load faster, and it all make a difference to the user. I really do hope you consider this more deeply, is it really more important to support browsers legacy browsers like IE6 that have have single figure usage percentages in country's outside of asia and africa, and which has also dropped 3% of those users in the last three months, than it is to provide a quality cutting edge framework. You asked is this really a problem for my application the answer is yes. While half a second is not a long time it is very noticeable, and it is something that caused me to spend the afternoon looking at alternatives. I do not feel comfortable delivering a product that has such obvious deficiencies. I accept that network delays might cause this type of delay anyway but why punish all my users. RAP has a good niche at the moment being able to run on both desktop and web but with technologies such as Titanium http://www.appcelerator.com/ and GWT combining that wont last forever. Sorry for my rant by I do feel you need to at least consider this improvement. Cheers, Tim
Timothy, I agree that responsiveness is key in UIs, but I'm still reluctant considering the effort compared to the gain. From my point of view, the 500ms are a perfect compromise between responsiveness and performance. But that's just my personal view. When you think that this is a real issue, which you obviously do, please feel free to reopen the bug, but set the severity to "enhancement" and change the bug summary to reflect your suggestion.
