MOTODEV Blog

[#1]

I’m always on the look out for new software tools, so was delighted to learn about a utility created by experienced developer Jens Riboe, based in Sweden.   A couple of years ago, Jens wanted to demo an app, with the device screen mirrored to his PC.   At that time there wasn’t a good utility to repeatedly capture screenshots and display them on a host PC.   If “necessity is the mother of invention,” tight deadlines are probably the taxi driver rushing the mother to the delivery room.   Or something.  The point is, Jens got the screen mirroring utility working in time for his demo three days later.

The app demo was a success, and Jens generously published the quick hack on his blog so that everyone could use it.  Jens gave it the name “droid@screen”.  He then moved on to other projects, and didn’t look at droid@screen for about a year.   By then, many developers were making good use of it.  So Jens decided to spend some time improving the software, up to its current state, version 1.0.1.  (Open source projects infrequently get to version 1.0 or later!)

Droid@screen is a Java Swing app that runs on the host PC.  It uses the Android debugging API to take a screenshot on the mobile device, then pull the image file back over USB onto the host, where it is displayed.  The app repeats that over and over, so the PC shows any new stuff that happens on the device.   Droid@Screen is mostly used to give demos, and help with training. It’s an alternative to pointing a video camera at the device.  Video feeds are frequently not handled correctly by screen-sharing software, so droid@screen gives you the same effect and works reliably with screen sharing.

Figure 1:  the Droid@Screen control panel, just start it up and go

The limiting factor on frame rate is the speed of the USB connection, believe it or not.   With a phone from 3 years ago, Droid@screen could display more than a frame per second.  As higher and higher resolution devices have taken over the market, it now takes longer to get each snapshot.  Jens added some code to display the data transfer rate of each screen shot.   Figure 2 shows that it takes about 2.8 seconds to retrieve a 540x960 resolution screen image from my DROID RAZR.

Figure 2: the lower part of a screen image, showing size and transfer time

That is way too slow!   It’s moving 540x960 pixels, each represented by 4 bytes of color and alpha information.  That’s about 2 MB of data for each screen.   My development Mac has USB 2.0, which has a nominal speed of 480 Mbit/sec, or 60 Mbyte/sec.  Why isn’t it transferring each frame in 1/30th of a second?   Well, the nominal rate is 60 MBps, but that doesn’t include packet overhead, dropped packets, bus negotiation, collisions, cosmic ray effects, dust mites, etc.  The effective throughput for USB 2.0 is more like 30 - 35 MByte/sec effective.

So why aren’t I seeing 15 frames per second?  As I looked at my set up, I noted that I was using a USB hub.  It only took a few seconds to reconfigure so that the handset was directly plugged into the host PC.   That gave the immediate improvement shown in figure 3.


Figure 3: USB is 4X faster when it doesn’t go through a hub

When I make a direct USB connection, the frame image takes 0.66 second to get onto the development host - more than four times faster than going through a hub!  I could also make my adb connection to the phone over WiFi, instead of USB.  But 802.11g WiFi is about 10x slower than USB, so that will be worse not better.   The best way to speed up the frame rate is to reduce the amount of image data sent over the wire.  Since no part of the composite screenshot is transparent, you don’t need to send the alpha byte.  That’s an immediate 25% speedup.   I should still be seeing 15 fps, so there's more to look at here than just USB.  But part of performance optimization is knowing when it's "good enough" and you can move on to other tasks.

I saved the best information till last.  Jens open sourced his utility program, and you can find all the code on Github at https://github.com/ribomation/DroidAtScreen1.  So, if you feel like tuning this excellent app some more, you know where to find it.

Update:  Jens emailed me to query the poor performance I was seeing.   Here's the hardware inventory on my development Mac.  The line highlighted in blue shows the problem -- I'm using a very old hub that can only go up to 12 Mbps!  That's OK when I use it for the keyboard and mouse, but it really hurts when I plug a high performance computer (my phone) into it.  OK, I have to stop by Fry's and get a new hub!

Peter van der Linden
Android Technology Evangelist