Can you explain further? So you don't care really which viewer it is as long as you have something under /opt/TurboVNC/bin/vncviewer? Could that just be a symlink that points to the Java app? Need more information about your deployment scenario.
Further, the X11 viewer isn't going away ... yet. Long term, I really want to take the existing Windows source and strip out all of the Win32 calls and replace them with GTK and whatever platform-independent glue is necessary to bring up a native viewer on all platforms that looks & feels just like our Windows viewer. That is definitely a post-1.2 thing, though, and it won't happen before next year at the earliest. It's hard to secure funding for that project, since most TurboVNC users are either Windows users who don't care about the X11 viewer or Unix users who don't care about making it easier to use. Mac has always been the middle child of that family, but now we're forestalling the need for a native Mac viewer somewhat by providing a really slick Java app that is tailored to that platform. With 1.2, even if the X11 viewer binary goes away, it will still be easy to build it from source. I'm just proposing to no longer provide a pre-built binary for it on Mac and instead to make the Java viewer the "Mac viewer", to document the X11 viewer only as a solution for "Unix/Linux" and assume that anyone who wants to use it on Mac would understand how to use Mac as a Unix platform. In the current pre-release builds, both X11 and Java viewers are provided in the same DMG. All well and good if there are clear advantages to both, such as better performance with X11, but that doesn't appear to be the case, so I don't want to confuse the users. However, let's discuss-- if you don't need the X11 viewer per se and only need the same filesystem interface, I can provide that using the Java viewer. There is still the matter of how to package the documentation, so I may end up having to package the .app bundle inside of a .pkg anyhow, and that would give us the ability to install sym links under /opt/TurboVNC. I am uploading the benchmark files and will send you a subsequent message with instructions. On 10/3/12 4:51 PM, James Wettenhall wrote: > DRC, > > I'm happy to help with Mac OS X performance testing if you send me > instructions. I think your proposal to remove the X11 binary from the > Mac distribution sounds reasonable for future releases, but you're not > suggesting removing it from the 1.2 release are you? I would have to > change my code, because if it can't find /opt/TurboVNC/bin/vncviewer, > then it assumes that TurboVNC viewer has not been installed. (On > Windows, my code checks the registry.) > > Cheers, > James > > Sent from my iPhone > > On 04/10/2012, at 3:28 AM, DRC <dcomman...@users.sourceforge.net> wrote: > >> I guess I had been assuming that the X11 viewer was faster on Mac in the >> aggregate because it was faster on Linux and because the smaller 2D >> datasets I happened to be using for quick & dirty benchmarks were faster >> with X11 than with Java on Mac. However, I hadn't actually done a full >> benchmarking shootout on that platform until now. I just did the full >> comparison of all 20 "canonical" 2D and 3D datasets, comparing the >> latest Java viewer code with the X11 viewer running in XQuartz 2.7.4 as >> well as in XQuartz 2.3.6 (the version that shipped with OS X 10.6.) >> This was done both on my 64-bit 2009 vintage Mac Mini as well as my >> 32-bit 2006 vintage Macbook, and the results were surprising. On both >> platforms, the decoder was slower in Java, as expected (25% slower on >> both platforms, vs. native.) However, the drawing was so slow in >> XQuartz that the Java viewer managed to pull ahead and finish about 15% >> faster on the Mac Mini and 27% faster on the Macbook, relative to the >> X11 viewer running in XQuartz 2.7.4. Relative to the older XQuartz that >> Apple used to ship, the Java viewer was 32% faster on the Mac Mini and >> 65% faster on the Macbook. >> >> I'd be really interested to see if any other Mac users can duplicate >> these findings, particularly on a higher-end Mac (the Mini has a GeForce >> in it, but still not a Mac Pro by any means.) I'll be glad to send you >> my benchmark datasets and instructions on how to run them and collect >> the data. If these findings continue to bear out, then it would be >> worth considering dropping the X11 viewer from Mac altogether, so if >> there are any strong objections to that, I'd be interested to hear those >> as well. I mean, it will always be possible to build it from source. >> The idea is that I would just not package the X11 viewer as a binary on >> that platform anymore, and the Java viewer would be the documented >> solution for Mac. >> >> There is one major feature that the Java viewer lacks, which is keyboard >> grabbing support, but in fact, that feature doesn't work on Mac with the >> X11 viewer, either, and it's less critical on Mac, because the >> keystrokes that one typically needs to grab (Alt-Tab, Ctrl-Esc, Windows >> and Menu keys, etc.) aren't captured by the operating system. Thus, I >> think that, in general, it might be a perfectly reasonable thing to just >> ship the Java viewer. Yeah, OS X 10.7 doesn't include Java by default, >> but neither does it include an X server by default. >> >> DRC >> >> ------------------------------------------------------------------------------ >> Don't let slow site performance ruin your business. Deploy New Relic APM >> Deploy New Relic app performance management and know exactly >> what is happening inside your Ruby, Python, PHP, Java, and .NET app >> Try New Relic at no cost today and get our sweet Data Nerd shirt too! >> http://p.sf.net/sfu/newrelic-dev2dev >> _______________________________________________ >> VirtualGL-Devel mailing list >> VirtualGL-Devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > VirtualGL-Devel mailing list > VirtualGL-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-devel > ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
