John Hu had wrote some services running on Banana Pi a few months ago. It is so incredible that Banana Pi is so stable. The services had run about 3 months and merely didn’t be down only for a few network issues. One of the services is an audio conversion service which supports miidio space. Currently, there are 5 services running on Banana Pi. 3 of them run daily and 2 of them run hourly. This hardware is so stable.
John Hu had also tried to run a coin miner on Banana Pi. But its CPU power is so weak, comparing to a normal PC. And there is no GPU version miner for this kind of hardware. So, I turned it off with no coin got. That’s so pitty. I think they will open their source of GPU driver. And it is possible to do such kind of miner.
An app with a lots images brings memory pressure in mobile world. In Android, they tries to recycle the existing UI elements to show images. The original image is freed automatically when the UI element’s image source is changed. That’s handled by Java’s reference count, IIRC.
We have similar tricks in Firefox OS. Gecko, the core engine of Firefox, has an image visibility monitor tool. It releases the uncompressed image when an image is out of screen, but keeps its DOM structure for other updates. That brings you a fast and easy way to manage your gallery view.
Besides Gecko, Gaia, the code name of apps level of Firefox OS, also has a visibility monitor. It tells the app which UI element is in or out of screen. We can use it to free or load image on to img element. It helps Gallery app out of memory presure issues.
The difference between Gecko’s version and Gaia’s version is that the Gecko version releases the uncompressed image but keeps the raw image which is compressed image downloaded from server, like JPEG or PNG. The Gaia version takes images off the UI element which releases both uncompressed and compressed images. The memory usage of Gaia version is lower than Gecko version. But the scrolling performance, FPS, of the Gaia version is worse than Gecko version because the Gecko needs to download the images from server or file system in the Gaia version. This document focuses on the Gaia version.
How Does It Work?
The example of visibility monitor
The above image is the definition of each area of a scrollable frame. We have pre-rendered area, display port area, margin area, and non-rendered area to comprise the all area. Images in pre-rendered area are loaded, uncompressed and rendered. The full area is the height of display port + 2 x margin. The display port is the real area shown on the screen. The margin area provides a buffer to make scrolling more smooth. The larger margin area brings the higher FPS and larger memory consumption. The default vaue of margin in Gecko version is a size of display port area. We don’t have the default value in Gaia version.
There is only one function in tag visibility monitor, which is monitorTagVisibility. It takes 6 arguments:
container: the scrollable element we want to monitor the children
tag: the tag to monitor
scrollMargin: the size of margin area
scrollDelta: how much the container needs to be scrolled before onscreen and offscreen are recalculated. The higher value means callbacks fired less frequently, but there are more of them when they are fired/
onscreenCallback: called with the element that is now onscreen
offscreenCallback: called with the element that is now offscreen
An example can be found at Gallery app in v1.3t branch:
varvisibilityMargin=360;varminimumScrollDelta=1;visibilityMonitor=monitorTagVisibility(thumbnails,'li',visibilityMargin,// extra space top and bottomminimumScrollDelta,// min scroll before we do workthumbnailOnscreen,// set background imagethumbnailOffscreen);// remove background image
The thumbnails is the DOM element container which hosts all thumbnail items. The tag name of thumbnail item is “li” according to this example. We use 360 which is the 3/4 height of the screen size and 1 as the scrollDelta. We just set or remove the background image in the onscreen/offscreen callbacks.
The Performance of Visibility Monitor
We choose the low-end device, Tarako, to show the performance of it.
The memory consumption of Music app without visibility monitor is:
Laser Pointer Tracker System was an old project proposed and executed by John Hu 4 years ago.
It was a software-based human computer interaction device. It could detect the laser pointers by computer built-in camera. It used computer vision to locate the position of laser pointers in camera and coverted them to computer coordinate system.
The first example was to control a power point presentation with a laser pointer and gestures. This example is made with Win32 API and our owned gesture detections.
The second example was made by Flex. It is an interactive system, multile-touches photo gallery, and google map:
Have you checked the keyCode for keyDown, keyPress, and keyUp events of browsers? The values of them are different. Some of them are ASCII code and some of them are printable key code, what?! We can find the detailed rules here. we can check this to know more about JavaScript keyboard event
It would be nice to have a page to test it. John Hu had created one for this purpose. Since the modern browsers will repeat the keyDown and keyPress, this page prints keyDown and keyPress while you hold the keys.
Since I used Lubuntu for Banana Pi, the compiling procedure is similar to cubieboard. We can download the source from node.js and do the configure and make. But there is one thing different. We have to configure with an extra argument, otherwise we get the segmentation fault:
