Optimizing for mobile viewer is kept in our mind from the beginning. However we don't touch it until recently. From the data of profiling, we found the decoding takes much of time before the image rendering. In desktop browser, the performance degrading is not apparent for the CPU (mostly Intel architecture) is very powerful. In particular , depending on the browser implementation, some of the desktop browsers , say , Chrome run pretty fast and you even can't detect the sluggishness. However, for mobile browsers, due to the poor processor ( mostly ARM ?) , the CPU-intensive decoding does matter. During the decompressing, the main thread loses the control and the GUI shows no response. It leads to unacceptable user experience. Actually , such sluggishness could be also detected in some desktop browsers. From our observation, Firefox is really the worst one. Its performance is never improved even over ten major versions have been released.
Multi-threading is a well known trick to overcome the problem mentioned above. In HTML5 paradigm, webworker is born for this. We know what the webworker can do even at the day one, but we don't choose it in the first place in that we concern the the data transferring efficiency between the front page and the back end web worker. Not like most of the modern programming languages, say, C++/Java/C#, where shared data is used with thread synchronization mechanism, HTML5's webworker takes usage of a distributed model to swap data.
That being said, data will be never shared, but cloned. For small truck of data , it is not a big issue, however, for image processing , it is not uncommon to transfer big size of data produced from front end to the back end to process and then sent back to front end for rendering in a pretty high frequency to respond interactive operations of user. (The data cloning's overhead is significant. As a side note, we notice that chrome has now supported so called transferable object since 17+, but we do not try it yet since it is now only provided by chrome. )
Our second concern is the complexity to handle the webworker programming. Learn webworker's basic ABC is one thing, to program a product with it is another thing. Generally speaking, We did not want to put ourselves with uncertain risk at the project's early days and would not take the optimization too eagerly.
But now we think it is a proper time to work with webworker. Firstly, we will select a smarter algorithm to reduce the data clone times, that is ,we trigger the data transferring only when the user stops to manipulate the UI. For example, the data transferring will be hold during the mouse moving until the mouse up. In this way, we hope the user would not be effected by the latency. Secondly, we now have our prototype ready. We got a pretty good demo version for the desktop browsers. Why not take the optimization for the mobile browser?
After two weeks 's work, we did it. We finish the first demo version for mobile browser. Here is the takeaway:
1) Mobile chrome is still the best one with better user experience. But please note, this is for Android version. The iOS version of chrome is not as good as its counterpart in Android.
We are using the Google Nuxus 7 ( Android 4.1, Mobile Chrome 18) and iPad 2 (iOS 5.1, mobile chrome 18) as the test suites.
2) Safari in iPad2 is workable but not as good as Android's mobile chorme
3) Android's Mobile opera can 't work at all
4) Android's mobile firefox can work but sucks.
1) the CPU 's power is critical important for image processing. especially the main frequency.
2) Browser implementation is even more important than item 1)
3) The wireless connection capability of mobile devices can not be estimated. Nexus 7's http stack seems better than iPad 2.
For now, we put a demo version for the webkit family browser here for testing. So for better UX, please launch your favorite mobile chrome in Android 4.0+ to have a fun!
IE? Oh... man, forget it . Microsoft does not support webworker even in Damn IE9! It really sucks. It seems they are ruling them out from the internet era. God know what Microsoft is thinking!