Re: [VirtualGL-Users] libturbojpeg.a compile error: relocation R_X86_64_32 against .data can not be used

2013-06-14 Thread Nathan Kidd
On 06/14/2013 01:29 PM, DRC wrote: Both of you are misunderstanding a couple of things: (1) It isn't necessary to extend the CMake build system in order to link dynamically with TurboJPEG. (To be clear: I didn't mean to imply that was a patch that you should accept -- it merely made sense in

[VirtualGL-Users] Improving performance on very large displays

2013-06-14 Thread Paul McIntosh
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

Re: [VirtualGL-Users] Improving performance on very large displays

2013-06-14 Thread DRC
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

Re: [VirtualGL-Users] Improving performance on very large displays

2013-06-14 Thread Paul McIntosh
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