Good question. Our current Java viewer (which, in combination with native glueware, is used as the TurboVNC Viewer on non-Windows platforms) was originally a by-product of an effort to produce an Android TurboVNC Viewer back in 2012, but the project was never fully completed. Because I'm an independent developer, research projects like that often have to be implemented piecemeal as funding comes in for the various pieces, and it's often the case that, once a certain "critical mass" of pieces is implemented, it will be much easier to secure the funding for the remaining pieces.
By the time 2012 rolled around, the JNI interface for libjpeg-turbo already existed as a result of an unrelated project. Santos ponied up research funding for the next steps, because they were interested in using dockable multi-core Android phones as TurboVNC clients. I was able to use that funding to clean up, integrate, and test the initial NEON optimizations for libjpeg-turbo (from Nokia and Linaro), as well as to work with Brian (TigerVNC developer) to bring over his Java TigerVNC Viewer code and enhance it so that it behaved more like the Windows TurboVNC Viewer and so that it could use libjpeg-turbo via JNI. The reasoning was: get the Java TurboVNC Viewer infrastructure working first, then look at porting the GUI to Android from there. Unfortunately, the dockable Android phones never really materialized with the performance and features necessary for Santos to achieve what they needed (they drive 4-megapixel displays), and as time went on, Microsoft started producing tablet products that will run the native x86 Windows TurboVNC Viewer, so there hasn't been a big push for an Android TurboVNC Viewer in industry. I'm still interested in producing one, however. Since the latest release of Android now includes libjpeg-turbo, that might make things a bit easier now than it was in 2012, since it should hypothetically be possible to release a full-performance TurboVNC Viewer for Android that doesn't require a bundled NDK library. The real trick is going to be porting the GUI. I am adept at Swing programming, but Android GUI programming-- although it has a few of the same constructs-- is quite a bit different than Swing, and it would basically be necessary to design a whole new GUI from scratch that is mobile-friendly and that implements the same features as the PC TurboVNC viewers. All of the various dialogs and menus would have to be turned into touch-screen-friendly configuration screens, and I'd have to implement some mobile-friendly way to handle zooming, panning, scaling, resizing, etc. If I had to do this from scratch, I could easily see it taking more than 100 hours to get a proof of concept working, and more than that to fully test it, document it, produce builds in a somewhat automated manner, etc. There could be some reuse of the existing Java classes, but I'm guessing that maybe only half of that code could be reused (if that.) Unclear whether I could reuse any of the existing encryption classes or what other low-level features would have to be re-written to accommodate the Android O/S. GUI-wise, it might be quicker to build upon an existing GPL-licensed Android VNC viewer GUI and simply enhance it for our needs. That would certainly reduce the cost of the initial PoC. Regardless, though, this is either going to require someone donating a lot of labor or donating a lot of money. On 2/16/17 5:27 PM, Jason Kurtz wrote: > DRC, > > I know this is a question that comes up every year or more. I am > wondering how much do you estimate it would take to make a turbovnc > Android client. I have already complied and used virtualgl and turbovnc > on ARM Hard Float, and ARM 64. Even though there are other vnc clients. > When I tested them on the arm arch. Turbovnc blew all the other options > away. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ VirtualGL-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-users
