Well, it's important to understand that VNC will usually just send the
portions of the display that have changed ("incremental framebuffer
update.") It will send a full framebuffer update upon first connecting
and when specifically requested by the viewer (using the Refresh or
Lossless Refresh functions) or when the scaling factor is changed, etc.
The TurboVNC X11 viewer doesn't maintain a back buffer, and thus it
will also request a full framebuffer update if the window is
minimized/maximized or obscured. The Windows and Java viewers, however,
are smart enough to redraw the window's current contents without
requesting a new update from the server. All of that is somewhat moot
if you are using a full-screen viz app that updates most of the display
on every frame.
To answer your question, since the viewer is maintaining a copy of the
pixels from the server, a full framebuffer update will always send all
of the pixels from the server, even if some of them aren't visible in
the viewer due to the window size. The reason for this is both because
the logic would be inordinately complicated if it was only maintaining
the visible portion of the display, and also you wouldn't want to have
to wait for a new framebuffer update when using the scrollbars.
Downsampling on the server: Someone else asked about this, and I'm
going to look into the possibility of using the RANDR extension (part of
the desktop resize functionality that will go into TurboVNC 1.3) to do
this. However, I'm not really sure how useful it would be. I don't
understand why anyone would want to run the TurboVNC Server in a
resolution that is significantly larger than the client display, unless
they were broadcasting to multiple clients that support different
resolutions.
With downsampling, the text is quickly going to become unreadable. Can
you provide more details of exactly why you need to use a 24-36 Mpixel
display? Perhaps I can provide a more intelligent answer.
On 6/15/13 12:35 AM, Paul McIntosh wrote:
> Hi Darrell,
>
> Thanks - the client we just tried was a Windows one but we'll be trying a
> few. I'll give the multi-threading a go.
>
> For testing purposes, how out is setting a standard resolution screen to
> something ridiculous? Is it smart enough to down sample on the server side if
> the client is viewing in scaled mode? Or if the client is viewing in full
> res, but only a portion, is the out of view portion not sent?
>
> The point James just made is also something I need to try, I forgot to look
> if the ssh daemon was maxing out! And I should test with it without any
> tunnel at all.
>
> Cheers,
>
> Paul
>
> ----- Original Message -----
>> From: "DRC" <dcomman...@users.sourceforge.net>
>> To: virtualgl-users@lists.sourceforge.net
>> Sent: Saturday, 15 June, 2013 9:43:08 AM
>> Subject: Re: [VirtualGL-Users] Improving performance on very large displays
>>
>> Bigger pipes will definitely help, up to a point. The compression
>> ratio
>> you can get will vary a lot depending on the types of images that the
>> app is generating. I use GLXspheres as a sort of
>> "middle-of-the-road"
>> approximation, since it has a realistic proportion of solid color and
>> smooth gradient, one that you might see in a CAD or viz app when the
>> model is zoomed out to fit in the window. However, as they say here
>> in
>> the States, your mileage may vary.
>>
>> GLXspheres compresses to about 1.8 bits/pixel when using perceptually
>> lossless JPEG, about 0.75 bits/pixel when using medium-quality JPEG,
>> and
>> about 0.4 bits/pixel when using low-quality JPEG. Thus, for that
>> particular image workload to maintain 15 fps at low quality on a
>> 24-36
>> Mpixel display would require 10-15 Megabits/sec of bandwidth. Double
>> that for medium quality.
>>
>> It is also more than likely that you will run into a CPU bottleneck
>> once
>> you eliminate the network bottleneck. libjpeg-turbo is typically
>> going
>> to be capable of compressing perceptually lossless JPEG at about
>> 60-100
>> Mpixels/sec on a reasonably modern CPU core (maybe a bit more than
>> that
>> now-- my machine is 2 years old.) Add 30% to that for medium-quality
>> JPEG, and add 50% for low-quality JPEG (both are faster, simply
>> because
>> they generate less data for the Huffman codec.) So applying that to
>> the
>> GLXspheres example above, my particular machine might be capable of
>> compressing ~2-4 fps with a 24-36 Mpixel display, or perhaps ~3-6 fps
>> if
>> using low-quality JPEG.
>>
>> If the client and server are reasonably similar in terms of CPU
>> performance, then you can probably improve the situation by enabling
>> server-side multithreading (export TVNC_MT=1 prior to launching
>> vncserver.) This divides the VNC desktop into equal-sized tiles and
>> uses a separate compression thread for each. Even though the client
>> is
>> not multithreaded yet, typically libjpeg-turbo can decompress a lot
>> faster than it compresses, so enabling server-side multithreading
>> will
>> likely shift the CPU bottleneck to the client. Be sure to read the
>> section on multithreading in the TurboVNC User's Guide.
>>
>> I have funding to work on multithreading the client as well and will
>> be
>> looking into that later this summer. Can you clarify which viewer
>> you're using?
>>
>>
>> On 6/14/13 6:12 PM, Paul McIntosh wrote:
>>> Hi,
>>>
>>> I have done a couple of experiments with very large displays (e.g.
>>> 7680x4800, 7680x3200) and the performance has (understandably)
>>> dropped significantly.
>>>
>>> Are there any tricks to improving the performance or is it not
>>> worth trying? I recall multi-threaded builds but have not had a
>>> chance to try them out.
>>>
>>> The tests so far have been on less than optimal links - we will be
>>> trying a long hall 1G network soon (across Australia) and possibly
>>> a shorter 10G link (from one facility on campus to another). Would
>>> bigger pipes solve the issue or is the bottle neck be elsewhere?
>>>
>>> Cheers,
>>>
>>> Paul
>>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> VirtualGL-Users mailing list
>> VirtualGL-Users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
VirtualGL-Users mailing list
VirtualGL-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-users
