I am using flot.js library for my graphing needs, but the performance with the android webview is very poor. I have this graph on the webpage, and have a need to be able to scroll up and down. But scrolling causes what I liken to a "sloshing" effect (think water in a glass!).
If scroll down the flot graph "slips" upwards, and similarly if I scroll up the flot graph slides downwards before returning to its normal position. So if I scroll up and down quickly, the graph looks like its bouncing around and overlaps the title and footer (as seen below).
I have tested this on a desktop, and the problem disappears so I believe it has something to do with the canvas or webview performance.
As anyone run into this problem before and know how I can get the flot graph to behave and stay properly aligned?
sample flot graph http://img543.imageshack.us/img543/1627/kpy4.png
UPDATE:
Android 4.4 now uses chromium for the webviews (almost chrome, basically) and the performance is a lot better.
~~~~~~~~~~~~~~~~~~~~~~~
Perhaps not the answer I, or anyone else is looking for, but I have discovered the problem to be a combination of poor flot.js and poor android webview performance.
The android webview, as noted many times on this site, has subpar performance for intensive js applications. Turning on hardware acceleration did not help in this case.
Additionally, flot.js does not perform terribly well either. In talking to a colleague, he was able to cut the loading time needed for his application by almost a factor of 100 by writing pure javascript instead of using flot.
TL;DR: Android WebView == Flot.js == slow
Related
This is less of a code-based question and more of a best practices-based question I suppose.
I built a scrollytelling data visualization with svg elements using d3.js. While it works just fine on my desktop, it lags quite a bit on mobile (I'm thinking perhaps because mobile has less cpu/ram capability). While making it responsive using chrome dev tools for mobile, I suppose I figured because it looked fine for that particular device (which it does design-wise), it would render the elements just the same performance-wise (which it does not when deployed to an actual hard device).
I suppose my question(s) is - Is there a best practice for preventing something like this from happening? I'm assuming I should have staged this on an actual device earlier so I would pick up on something like this occurring. Moreover, (and perhaps a dump question), are there well-working svg-to-canvas converters that would allow me to override this problem (are these even a thing?), so when device width & height is detected, it would run the canvas-copy as opposed to the original svg code which is better suited for more powerful/capable devices?
Many thanks.
I am working on a HTML canvas app that displays graphics to the screen. The graphics aren't important for the website, they just make things look pretty.
My problem is the app needs the cpu of the device to run at a certain speed or the frame rate becomes unacceptable.
Any modern phone/laptop can easily run the app, but of course not everyone has updated tech.
At that point I'd like to drop support for the device and stop rendering the animations because it will just do more harm than good.
This idea is pretty standard on the internet. For example if you want an image background for your site, but you don't want mobile phones to load the same large image as desktops then you just use some css queries to only serve the image to desktops.
This is how we can get new features pushed out while keeping backward compatibility.
However when it comes to detecting performance this isn't as easy of a task as it sounds. There's no way to get cpu specs with Javascript, and even if I could there's no way of telling what else the user is running on their machine.
This leaves me with 2 options, either run a small performance test before I start the canvas app. Or start the app and try to run a few frames and stop it if the frame rate is too low.
The problem is both of these options are pretty sketchy because the device may just have a "speed hiccup" at the start of the app, and so I shut down the animations for nothing.
Also if a user has a device that sits right on the border of the threshold sometimes the animations will load, and sometimes they won't which would probably be confusing.
Is there any "standard" on the internet to deal with this sort of problem? Would it be best to leave a footnote at the bottom of the site window when animations are turned off?
Or is it just something you have to accept when pushing the boundaries and dealing with performance?
Anyone out there done reserch or have real good experience with 3rd party scroller's for apps running in a webview? Especially with more than one divide that scrolls?? i.e. A webview with a navigation panel and a details panel.
When there is only one divide requiring a scroller, it works smoothly but in the situation above, its very choppy. I'm sure a lot of developers have encountered this issue.
I have tried iScroll (and is best so far) along with other plugins but the quality of the scroll is less than desirable. I can't use iFrames because I need to tweak the style of some HTML docs that are pulled from our server. I've searched online for a way to invoke the native scroller in HTML divides and haven't found a way to. Is there a way and how could I do this?
I've been playing around using API's 9 thru 15 on various devices and I'm not seeing any difference when it comes to the performance of a non-native scroller. I'm currently developing the app on 15 if this is a help to your answer. Also, I have hardware acceleration off and this works best.
I've played with jqm, Sencha, and alike and they seen to have satisfactory scroller's. Does anyone know what they use? The issue why I'm not primarily using any of these platforms is the bulk and other performance issues.
Currently I'm building an app using raw javascript and this is proving to have a significant improvement in performance over all in animations within the webview layouts - Significantly better over any of the big name cross platform solutions. Unfortunately I am not experienced enough to build my own scroller so I need to find an out of the box solution.
Any ideas, leads or solutions so others that are better at writing apps with javascript can have a fighting chance building quality apps would be very appreciated.
With you experiences and experties, please include what API level you were using.
Thnx
I did many tests about this. I won't recommend a third party scrolling based only on HTML because on my experience the problem is not the javascript, but the webview itself:
1) Iframes performance on WebView is weak weak weak. I got a nearly 40% decrease on performance for any (complicated) app just for placing it inside an iframe. Besides, they cause much more problems if you use hardware acceleration.
2) Scrolling of DIVS is acceptable if stuff in divs is simple and SHORT, but the performance decreases as you add more elaborate stuff to scroll. For example, in my case it made a difference to enclose everything in ul/li's (slower) or not (noticeabily faster). However, the feeling is not perfect, ie., if you are used to native scroll, you realise this is not native scroll.
3) Raw scrolling of the body is very good. Besides, you get native-like feedback, such as the glowing effect on overscroll, etc. But mind that this scroll is NOT using javascript, it's just a page bigger than the webview that you let the user to scroll and WebView takes care of it. In my case, this was the only acceptable scroll experience I wanted for my users.
So I came with a mixed solution: I did a JavaScript-callable Java function that would open another webview with requested size like if it was an iframe, so I could open it from HTML and fill with stuff, it was not very difficult to do, and the improvement was awesome.
More things:
4) Scrolling a WebView from Java (scrollTo) was very useful in my case, where I had a huge HTML page loaded (kind of a magazine) to be swipped. Performance if I asked the webview to scroll from Java was much, much, much better than relying on JavaScript to do the scroll.
5) Hardware-Acceleration improves the scroll speed a 100% -setLayerType(HARDWARE)- but to be able to use it you have to keep you html very very simple. stuff like Display:none/block, etc completely break the application (see WebView fails to render until touched Android 4.2.2 for more info)
6) HTML5 animations on big images completely kill the scrolling experience.
7) All this is not valid in a couple months, goole is replacing the rendering engine to "Blink", so who knows what's gonna happen. I am restless.
Does anyone have experience displaying large set of data using JavaScript InfoVis Toolkit? Basically, I am doing research on how my project can provide visual representation of social network... and playing around with JavaScript InfoVis Toolkit I did not notice any performance degradation... meanwhile I saw this:
JavaScript InfoVis Toolkit - interaction seems a little slow, maybe that's on purpose in the demos from
javascript framework for relationship visualization
and
JsVIS is pretty nice, but a little slow with larger graphs. from
Graph visualization library in JavaScript
this makes me worry that under real data it might crack? So just asking..
plus i looked at Flare, it seems like another good alternative, but looking at their site it looks like it hasn't been updated in almost 2 years... is it totally outdated?
To answer my own question.... performance is not that great. I wrote a script to populate json object used in ForceDirected object with 100 nodes and it was terribly slow... will give www.graphviz.org a try.
It's quick enough if not using such things like gradient background and other processor consuming visualisation.
I made Sunburst with 3 levels and about 100 nodes. Quick enough.
OK, I'm totally biased here (disclaimer: I'm an author of it), but KeyLines can handle several hundred nodes just fine - it is commercially licensed.
In general terms - aside from the issue of what framework to choose - I've found that canvas performance depends strongly on whether the browser+device has hardware acceleration. For example, before iOS5, iPad performance for canvas in Safari really was dreadful, but since iOS5 it flies along. Android is more variable. Most desktop combinations of browser/OS are now fine for high performing canvas rendering.
Another consideration for graph layouts is whether long running layouts block the browser's rendering loop - we've had to develop around the issue of long running (i.e., more than a few seconds) tasks locking up the browser. Users like to see progress bars ticking along & that is possible provided you take the right steps in the layout code..
I'm developing a site which has a flash background playing a small video loop scaled to fill the whole background. Over the top I have a number of HTML elements which are animated using javascript. The problem I am having is that (predominantly in FF, but also in others to a lesser degree) the flash seems to be causing my javascript animations to run rather jerky, and in some cases missing the animation altogether and just jumping to the end state.
Does anybody have any thoughts on how to make the 2 work together nicely?
Many thanks
Matt
You'll notice the same effect on BBC Iplayer - if you've played a few videos, then use the left and right scroller. The javascript animation is no longer smooth.
The is more noticeable in FF.
Chrome creates an entirely separate process for the flash, and therefore smoother, Safari is quite lightweight therefore smoother at times.
Bit of a bugger really - the only thing I can suggest is ensure your swf is optimised for CPU - if it contains lots of code, ensure you doing good memory management.
I had the same trouble once and I targeted FP10 - this offset a lot of visual work off the CPU (therefore the current process in the browser) and gave it to the GPU.
--
Aside from this, you're pretty much at the mercy of how powerful the clients machine is.
Additional for my answer above:
Thanks Glycerine. Do you think there would be any performance improvements if it was compressed into an older format? Or even just a SWF? There is no audio, so it's just an animated background really. – - Matt Brailsford
I think a newer format would be better - if you can do FP10, then again, you'll be able to utilise the user GPU, if your working in CS3, best to go for FP9.5.
Ensure your stage objects are cached for bitmap if your using large vectors
http://www.adobe.com/devnet/flash/articles/bitmap_caching_print.html
This ensures any heavy animation (even animation we regard as light) will run smoother because there turned into pixel data as opposed to complicated vector information. Its a small fix but it may work.
Try and target the AS3 engine as well. Even if your not using code. I keep saying it runs better than the as2, as1 engine with arguments from people but I'm sure you'll find your favourite camp.
If you have very large images scaled down, use a smaller form factor by photoshoping then to a smaller size. This will not only improve rendering speeds, but also swf file size.
Try those.