I have participated in a real head scratcher, and I was hoping someone would put some light on my issue.
The application I am writing is a JS based client, which is a desktop-sharing service. The service takes images from the desktop, encodes them as base 64 encoded JPIS and sends the JS client to the webcot. The client then displays these images (as the data URI), the user can move the mouse over the image as well as the image, as well as these mouse events are encoded as commands given in XML Are kept in queue and every 15ms, in such a way, the queue can be searched for redundant or duplicate orders before being sent for service. These commands are then executed (generate click events on the desktop, move the mouse etc.), and new desktop images are produced and the cycle continues.
The whole system works very well, some very inconvenient behavior on the Safari on the iPad. Basically, when the user transfers their fingers around the screen, the client appears to be blocking (or possibly de-prioritize) incoming messages on the websocket, in favor of sending outgoing messages, it appears that the way you Move around your finger, until you are touching the screen, the updates will not be displayed, then when you lift your finger, the flood of image updates will be triggered by the on-message () The reception will be received, which again gets animated on the screen in rapid succession.
Mobile Safari is the only browser that treats this way, none of the desktop browsers, or any Android tablet that I have tested, is showing the same behavior.
I have entered inbound and outbound methods on the websocket, and I have seen that behavior confirms that on Safari, I will get several outbound messages, after which there will be many inbound messages, while on Android, I see inbound and outbound message interwavings, because you drag your finger on the screen, as a result of which the display on Android is dragging around your finger. Will continue to update.
The main reason is that I suspect the websocket as a culprit because the client has a fallback mechanism, so if the browser does not have website support, a pair of XHR objects is created (one for inbound And one for outbound) and is used in place of webcot. If I force Mobile Safari to use XHR instead of websites, then the problem is solved. In this case only the communication system changes (all the codes remain the same for capturing input events and displaying images).
I know that this is a very specific problem, and without diagnosis it is very difficult to diagnose, but I have opted not to post the code due to the sheer amount of code in the client.
If anyone knows what I have described, or possible reasons for this behavior, I would be very grateful for your input.
Depending on the size of the packet, you face the problem of 'big' messages, a lot on the safari Slowly (on both iPad and desktop) Have you tried Desktop Safari?
To see the performance comparison between different browsers, see.
It may be that this is your problem.
No comments:
Post a Comment