Ah, well for the purposes of simulating the full-size display,
client-side scaling (which is already implemented in both the Windows
and Java viewers) is probably what you want. When you use client-side
scaling, the server still sends full-sized updates, and they are
decompressed on the client into a full-sized back buffer, but the back
buffer is scaled as it is drawn to the screen. Thus, you get virtually
the same bandwidth usage and CPU usage on both ends as if you were
displaying to a full-sized display, but it is scaled to your screen real
estate.
The wildcard with client-side scaling is that I don't have a good sense
of how much it slows down the blitter, and it may in fact slow it down
enough to where blitting becomes a bottleneck.
On 6/15/13 6:06 PM, Paul McIntosh wrote:
>> Can you provide more details of exactly why you need to use a 24-36
>> Mpixel display?
>
> I support a visualisation cluster which is a number of partners. One partner
> has large 6 screen displays all over Australia. Another Uni on the other side
> of Australia has just installed multi-screen display. Also we'll be
> installing a Cave/Vis-wall (of which I have been asked to come up with some
> demos). So it would be nice to be able to support direct realtime vis on
> these systems.
>
> I don't yet have direct access to these systems myself, so the question on
> scaling etc is with the view to testing on any machine (just by setting a
> large screen size), with the results somewhat representative of how it might
> act on a real display. It appears the answer is yes - so I'll test with that
> and see what I can come up with.
>
> I'll post some results.
>
> Cheers,
>
> Paul
>
> ----- Original Message -----
>> From: "DRC" <dcomman...@users.sourceforge.net>
>> To: virtualgl-users@lists.sourceforge.net
>> Sent: Sunday, 16 June, 2013 4:05:37 AM
>> Subject: Re: [VirtualGL-Users] Improving performance on very large displays
>>
>> 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
>>
>
------------------------------------------------------------------------------
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
