DRC <dcomman...@users.sourceforge.net> writes: > 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.
I think a command line client on Android for TurboVNC would be a useful start. I made a similar thing some years ago, where I ported a CLI sound generator C program to Android. Then we made a gui frontend that controlled the CLI program through stdio. While a bit primitive, it worked well enough for us. > > > 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 -- Joakim Verona joa...@verona.se +46705459454 ------------------------------------------------------------------------------ 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 VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
