I am making digital instruments for a car. These instruments will be constantly updated by information through ajax. These instruments will be served from a server onboard the vehicle through WLAN (fast) to my iPhone 3G. Is imperative to the success of the project that the updating of the tachometer is smooth and very responsive. Otherwise, it will look retarded.
The first problem I encountered was when I made this demo where tachometer moves quickly back and forth between zero and a thousand RPM: http://www.kingoslo.com/instruments/ When viewed on my iPhone 3G, the arrow simply doesn't move back and forth smoothly enough.
This javascript works by changing the source of the arrow img-element (which is semi transparant {4 color png} floating on top the static picture of the scale {16 color png}, by the way).
I've been made aware of new image editing features in HTML5, and wondered if any of those, or any other methods will be more responsive. Also, I am getting an iPhone 4 for xmas, so that may be a bit faster, but I've got the feeling that it still will fall short for the current build, especially when I add the constant ajax updating that is required to keep the instruments change values as the driver drives along.
Thank you for your time. Any help is greatly appreciated.
Kind regards,
Marius
I think using canvas will result in much faster animation - it was created to handle drawing, whilst manipulating DOM elements is comparably expensive.
Mobile Safari is compatible with canvas.
Alternatively, you could try incorporating all the angles as one large CSS sprite, and then just manipulating its background-position CSS property (element.style.backgroundPosition in the JavaScript DOM API).
Related
I am developing an aframe project on my MacBook pro, late 2013. When running the project, the fan of my computer always spins fast, regardless which browser I use (firefox, safari, chrome) and the project size (also happens with a project just containing a simple a-box).
aframe-stats show me that my project (1028244 vertices, 342748 faces) still runs with 20 fps.
Is it somehow possible to limit the frame rate to 10fps in order to keep my computer quite? Or any other way to limit the flop-consumption of the aframe project? I already tried a native approach with sudo cputhrottle plugin-container 10 but that did not just throttle the aframe-renderer but the whole firefox browser. Can I pull the break somewhere in the JavaScript or the Browser settings?
It's difficult to say without your project code. Large data sets will simply crank out even a high spec macbook pro. I have found it helpful to pause any rendering whenever possible to quiet the users' machines.
I personally removed automated next animation frame rendering in favor of waiting for controls and objects to change.
For example:
this.controls.addEventListener( 'change', function(e){ addToRenderStack(); });
A simple function addtorenderstack puts in a new value in a list for a render, with the expectation that the render will occur at some point in the future and not right away. the list can also be used to log who requested the render in the call stack, and narrow down performance hogs.
addtorenderstack places a render request in a list. In the requestanimationframe loop, if the list has any length, a render is called on the scene. The stack is immediately cleared rather than processed one by one. If controls or animations continue to make render requests, the list will have a length again and request animationframe will process them in the same way with another render.
In this way, the code only renders when absolutely required. This saved me much grinding on framerate and the fans only come on during intensive operations and then shutdown when its complete, much like a typical 3d game experience.
Your mileage may vary depending on what's happening in your app. I work in engineering so often the view of the 3d world is stopped as an engineer examines or shows a model.
I have a custom ListCell implementation, shown in the picture below.
The left side, which represents the date, consisting of 3 labels, put in a VBox and the "CounterContent" consisting of the counter, with a TextField for each digit, contained in a HBox, and two Hboxes containing labels for kWh, kWh/day and so on. And that seem to be just too much, to be running performantly.
I've tried to load the data in a background task, showing a progress indicator, while the task is running, but unlike on desktop, on android the performance is very poor. Whenever I switch to the listview, the garbage collection kicks in, and blocks the ui thread, so that the progress indicator never shows up.
I've tried it on a Huawei Y-300, Android 4.1.1, javafxports 8.60.6 (because javafxports 8.60.7 causes a bug, that makes TextField unusable), and on a Samsung S5 mini, Android 5+. On the Samsung phone the performance in general is way better, just like expected, because of the Ahead-of-Time compilation I guess, but there is still the garbage collection issue. Furthermore after the listview has been populated with cells, the scrolling is not very smooth.
Is the listcell to complex or what else could be the matter for the poor performance?
UPDATE:
After running a lot of tests it seems the unsmooth scrolling is not caused by performance problems. At least on the S5 (javafxports 8.60.7).
I removed all css styling, and replaced the textfields by a single label (the counter node is already a custom control(forgot about that), which lays out the textfields in 2 Regions(not HBoxes) and the nodes of the ListCell are instantiated in the constructor). Furthermore I switched the ListView for a CharmListView and set android.monocle.input.touchRadius=1.
None of these steps resulted in considerable improvement.
Just to clarify: In contrast to the Huawei phone, the scrolling on the S5 and android 5+ is usable, but it's not very smooth, which makes for a unsatisfactory user experience.
On the Huawei (javafxports 8.60.6), changing the counter textfields for a label, gave a significant improvement, but not to the point where the scrolling became usable. Until I set this magical experimental switch: gluon.experimental.performance=true, which makes the listview scrolling lightning fast(after a little warmup delay), but still not really smooth.
There are many reasons why the performance of a complex scene is reduced, so this is just a list of possible ideas that might help improving it, in any order.
ListCell
For starters, the number of nodes in the cell is really high. Notice that every single scroll you make means the full rendering of the virtual flow that holds the visible cells. And for every cell, that means recreating its content all over again.
Without viewing your code I can't tell, but you should avoid creating new instances of every node in the cell all the time, by having just one single instance, and in the updateItem method only change the content of the nodes.
Have a look at this sample. The NoteCell class is a custom cell, where a ListTile is used.
Number of nodes
Have you tried using just a Label to replace the 8 textfields and 3 boxes?
Cache
If you use images downloaded from Internet, use Gluon Charm Down Cache to avoid the same image being downloaded over and over again.
Have a look at this sample. Without the cache, even on desktop the performance is really affected.
Also use the JavaFX built-in cache for any node, trying different cache strategies.
CSS
Complex CSS requires long CPU time. Try to simplify it. Even you can remove the whole CSS for a quick test. Then decide what you may or may not use.
The same goes for animations: Avoid animations, transitions or even CSS effects, if possible.
Custom Control
The counter complex node could probably be replaced by a custom control that optimizes the rendering.
CharmListView
Have you tried using the Gluon Charm CharmListView control instead of the ListView?
There's a new experimental flag that you can use to test a possible optimization that might improve performance while scrolling the list. Set gluon.experimental.performance=true on the java.custom.properties file, and give it a try.
JavaFXPorts version
You mentioned you are using 8.60.6 because of the TextField bug. In this case, are your TextField nodes editable? If not, I'd suggest replacing them with other nodes and running with 8.60.7, since it contains a lot of performance improvements.
Performance tools
Use performance tools like Monitor and use its profiling options so you can trace down any possible bottle neck.
CPU
Last but not least: your mobile device specs are always critical.
Trying to render a complex scene on a Cortex A5, given that "it is the smallest, lowest cost and lowest power ARMv7 application processor", or using a very old Android 4.1.1, can't perform as well as running it on a brand new device with higher specs.
As you also mentioned, running on a Cortex A7 performs "way better". Have a look at this comparison, and find the right architecture for the job.
Anyway, there's always room for improvement, and a lot of effort is put into it. Your feedback is always welcome.
I'm working on a site with lots of CSS3 transitions (which are hardware accelerated) and high memory objects (for example, an array of 39 objects, each containing the full html source for a typical online news article) and I'm noticing some very choppy/jittery scrolling, which I've been unable to debug.
I've kept these high memory objects out of the DOM, which should prevent them from affecting DOM performance, however, I can't help but think that they are still having a negative effect. I don't have code samples to post because I'm unsure of whether this is even an issue.
Please go to this site (Orange) and click on an article tile. In the reader div that pops up over the page, try scrolling as you normally would. Does it feel choppy/jittery? Do you have any suggestions on how to improve this?
CSS3 transitions, opacity, text and box-shadows and the like are certainly known to impact rendering speeds. In fact, even sites with heavy use of text-shadow alone can cause choppy scrolling on the average computer. Combining this with heavy use of javascript seems like a recipe for choppy web browsing.
edit: The loading animation on the o in orange is pretty awesome!
Yes, that's jittery. A page with a lot of Javascript will do that and frameworks like jQuery won't help at all. I'd recommend recoding as much as you can without using jQuery and passing it through JSLint (http://www.jslint.com/).
Try using Chrome's developer tools too to get an idea of what the bottleneck is.
Try disabling Javascript too and seeing if it's any better. If it isn't, then you know where your problem lies.
I'm developing my first Android game and I'm having a bit of difficulty making the UI as smooth as I would like. I've spent a couple of hours googling around with no luck, I'm probably just searching for the wrong thing.
I have two different XML layout resources where each layout contains just one SurfaceView subclass. When I call activity.setContentView(R.layout.second_layout) to transition from the first layout to the second layout there is a noticeable period of time where a black screen (with a small white bar along the top) is displayed in between the two views.
I've tried various things such as; constructing the second view manually at runtime (i.e not using a layout XML file), calling activity.overridePendingTransition(android.R.anim.fade_in, android.R.anim.fade_out) after activity.setContentView(R.layout.second_layout) and attempting to render to the canvas before the view has loaded (turns out the canvas is unavailable).
I don't see other games (or apps) having this issue so I presume there is a reasonably simple solution.
If you need some more information about my particular situation in order to help out then please let me know what information is missing. Any help would be largely appreciated.
Update: My answer below was written in 2010. Since then Fragments have become the norm, particularly since Fragment nesting was made possible and the support library allows this functionality to be used in a backwards compatible fashion. As such, instead of transitioning to a new Activity to perform a new "user task", you can use the one Activity and push and pop fragments within that Activity's view hierarchy. Animations can also be performed as a part of a fragment transaction (e.g. Fragment transaction animation: slide in and slide out).
This became pretty apparent not long after posting this question, however I thought I should come back here and make it clear to everyone else.
Activities are positively the way to go when developing for Android. Don't be put off by the fact that a transition may seem too minor for a separate Activity, the very foundation of Android is built around the idea of an Activity.
I have an idea to implement a deep zoom type interface hosted in a browser for sports training data (speed, distance, heart rate etc.) However, rather than images I actually want to zoom into a hierarchy of information. For example, the initial display would contain a grid of years - hover over 2008, for example, and spin the mouse wheel (or click) will zoom into that year but during the zoom I want 2008 to fade out and be replaced with a calendar of months. Again zoom into a month and the months are replaced with the months calendar, zoom into a day and you finally see a chart with the training data plotted on it. All the time only dates with actual data would be highlighted in some fashion.
My question is whether this would even be possible and whether anyone has seen examples of this already. I'm imagining that most of the time the next level of information could be cached in the browser (in fact, because this is calendar-based, I can calculate most of that and cache the dates to be highlighted.) I could also zoom into an empty chart whilst an Ajax thread is fetching the data to display.
I've never tried anything like this before and I'm especially interested in whether DHTML would be capable of this sort of zoom (I suspect not and I would have to resort to Silverlight) and whether the Ajax execution would be uninterrupted whilst the browser rendering thread is kept busy zooming.
For Deep Zoom on images in JavaScript/Ajax there's the excellent Seadragon Ajax library by Microsoft Live Labs.
If you're looking into smooth and interactive zooming on content besides images such as text, video & vectors, have a look at the open source OpenZoom SDK I've developed over the last couple of months.
You probably could not achieve very smooth zooming with an javascript/ajax type interface, but a zoom interface would be possible. The pragmatic ajax book has a great chapter on implementing a Google maps clone. Theres no need for the technique to be restricted to zooming in and out of tiled images. The image elements can just as easily be any HTML you want. A fade effect could be applied to the zoom operation so when you move up and down a layer you get something similar to what you described. I recommend grabbing the book (Its a pragmatic programmers book, so theres a cheap and immediately downloadable PDF version available. Read the chapter, think about the techniques and then see if you think its practical for your vision. good luck.
Seadragon Ajax continues to evolve and is now OpenSeadragon:
http://openseadragon.github.io/
I've also been keeping a list of various zooming technologies, many of which use JavaScript:
https://github.com/iangilman/zooming
I don't believe ajax or dhtml are good solutions for what you are trying to achieve. I think flash/flex or silverlight may be the best option.
Check out the "scale" effect in jQuery. Here's a link. I haven't used it myself, but it might be able to do what you want. You'd have to swap out some content for different content at the right point, or your html would get too big.