That's fine. I'm reasonably sure your findings will match mine. One
other thing I've discovered is that the blitting performance measurement
in the benchmark is somewhat skewed in favor of the X11 viewer, at least
on the 2D datasets. The reason is that some of these benchmarks
(slashdot-24, for instance) involve typing into a window, such as emacs.
When you type into emacs, the area under the character you just typed
is changed, but the status bar at the bottom changes as well. Thus,
each framebuffer update contains two tiny rectangles, but the bounding
box for both of them is nearly the size of the full window. After each
framebuffer update is decoded, The TigerVNC viewer (upon which our Java
viewer was originally based) redraws the bounding rectangle for all of
the rectangles in the framebuffer update, rather than drawing each
rectangle individually. This is primarily to avoid overhead-- and
particularly in the case of Java, it's important, since the paint calls
in Swing are expensive. However, there are some corner cases, such as
the emacs window, that cause the viewer to draw tens or hundreds of
thousands of pixels for a framebuffer update, even though only a few
hundred pixels have actually changed. The X11 viewer, however, can get
away with drawing only the pixels that have changed, since it's using
bare metal X11 calls with basically no overhead. From a user's point of
view, this is probably not ever going to be noticeable. Who cares if
the viewer is drawing 100 characters/second or 1000 characters/second if
you can only type 5 characters/second? However, it does show up in the
benchmarks, since they decode and draw the stream as fast as possible,
without accounting for user "think" time. Probably a more fair
comparison would be with the TigerVNC native viewer.
The long and the short of it is, however, that since the performance is
skewed in favor of the X11 viewer, if the Java viewer is still able to
beat it, then there is no doubt that it's faster.
On 10/14/12 9:07 PM, James Wettenhall wrote:
> DRC,
>
> Ahhh, thanks!
>
> You did say "Untar into your home directory", but I incorrectly assumed that
> any subdirectory within my home directory would be OK.
>
> I won't try to run the scripts again straight away, because I have a couple
> of resource-hungry applications running at the moment which could affect the
> results, but I'll run them again later today.
>
> Cheers,
> James
>
> On 15/10/2012, at 12:29 PM, DRC wrote:
>
>> The scripts assume that the sessions are under
>> ~/rfbsessions.turbo.hiqual. If they aren't, then edit the script or
>> move the sessions accordingly.
>>
>> If that doesn't work, you may also want to rename them without a .txt
>> extension and chmod 700 on them so you can run them directly. Perhaps
>> running them with 'bash {script}' is causing problems, although it would
>> be a first in my experience if so.
>>
>>
>> On 10/14/12 6:31 PM, James Wettenhall wrote:
>>> DRC,
>>>
>>> OK, I finally have a bit more time to play around with this stuff.
>>>
>>> I have downloaded the session files and the attached scripts, and I have
>>> installed LibreOffice so that I can open the vncviewer.ods spreadsheet.
>>>
>>> Now I'm trying to run the "vncviewerbench.txt" script, e.g. using
>>> bash vncviewerbench.txt
>>>
>>> but I get an error:
>>> Testing bugzilla-16.rfb ...
>>> Could not open session capture: No such file or directory
>>>
>>> Am I missing something obvious?
>>>
>>> Cheers,
>>> James
>>>
>>>
>>> On 05/10/2012, at 7:45 AM, DRC wrote:
>>>
>>>> OK, here's the scoop:
>>>>
>>>> (1) Download the session files from:
>>>>
>>>> https://docs.google.com/folder/d/0B-KUeGuQMxsjVERKVGtCS2Y3MXc/edit
>>>> (Filename: rfbsessions.turbo.hiqual.tar.bz2)
>>>>
>>>> (2) Untar into your home directory.
>>>>
>>>> (3) Install the latest X11 viewer package for Mac (but note that this
>>>> procedure works with the Linux packages as well.)
>>>>
>>>> (4) Use the attached scripts to run the sessions through the TurboVNC
>>>> Viewer. Redirect the output to a file.
>>>> -- Make sure that you have shut down as many applications as you
>>>> can and that you don't try to do anything with the system while
>>>> running the benchmarks.
>>>> -- Your display resolution needs to be 1280x1024 or larger.
>>>>
>>>> (5) Use the attached parse_output script to extract the decoding,
>>>> blitting, and total time and copy/paste them into the attached
>>>> spreadsheet template
>>>> ('parse_output {output file} -d|-b|-t' extracts decode, blit, and
>>>> total time, respectively.)
>>>>
>>>>
>>>> How to recreate these session files:
>>>>
>>>> The sessions were created using the TurboVNC Benchmark Tools:
>>>>
>>>> svn co
>>>> https://virtualgl.svn.sourceforge.net/svnroot/virtualgl/vncbenchtools/trunk
>>>> vncbenchtools
>>>>
>>>> and the original, uncompressed set of session captures (that were
>>>> obtained via rfbproxy some years ago.) The original session captures
>>>> are described in detail in this report:
>>>> http://www.virtualgl.org/pmwiki/uploads/About/tighttoturbo.pdf. I am
>>>> in the process of uploading them to the same Google Drive folder (the
>>>> link to which is in (1) above) under the name rfbsessions.tar.bz2.
>>>>
>>>> cd vncbenchtools
>>>> mkdir {my_build_directory}
>>>> cd {my_build_directory}
>>>> cmake -DENCODER=turbo-1.1 -DDECODER=turbo-1.0 ..
>>>> make
>>>>
>>>> Now you can run
>>>>
>>>> ./compare-encodings -{depth} -to [-rgb] {input_file} -o {output_file}
>>>>
>>>> where {depth} is 16 or 24, depending on the depth of the session (the
>>>> filename indicates which) and -rgb specifies that the session used RGB
>>>> component ordering (needed only for googleearth and q3demo.)
>>>>
>>>> The default settings in the encoder use the Tight + Perceptually
>>>> Lossless JPEG encoding method, but this can be changed by editing
>>>> vncbenchtools/turbo-1.1.c, changing
>>>> compressLevel/qualityLevel/subsampLevel, and rebuilding.
>>>>
>>>>
>>>> Let me know if you encounter any problems.
>>>>
>>>> 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
>>>>> <mailto: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
>>>>>> <mailto: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
>>>>> <mailto:VirtualGL-Devel@lists.sourceforge.net>
>>>>> https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
>>>>>
>>>> <vncviewerbench.txt><vncviewerbench.java><parse_output.txt><vncviewer.ods>------------------------------------------------------------------------------
>>>> 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
>
>
> ------------------------------------------------------------------------------
> 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
