I'm very sorry for not including the version. If I had, I might have realized I wasn't building with version I thought I was.
I found I was building with VirtualGL-2.4.80.x86_64 (not certain where I originally found that tar). The official binary I was testing is VirtualGL-2.4.1.x86_64.rpm. I picked up the correct source for VirtualGL-2.4.1.x86_64 and compiled that. With the new source, I do not receive the '-c proxy' error any more. So egg on my face... To answer your question, yes. Previously, when I was building the incorrect version, '-c proxy' failed on Cygwin but not with TurboVNC. Even now with 2.4.1, Cygwin '-c proxy' still performs better than '-c jpeg' or '-c rgb'. With TurboVNC, I cannot tell the difference between any of the compression types -- they all seem very fluid. Perhaps, I've setup something incorrectly with Cygwin\X. I will re-investigate that, and re-read the documentation. Once again, sorry for my inaccuracy & false alarm. -----Original Message----- From: DRC [mailto:dcomman...@users.sourceforge.net] Sent: Thursday, September 03, 2015 3:58 PM To: virtualgl-users@lists.sourceforge.net Subject: Re: [VirtualGL-Users] ERROR: in FBX -- XCopyArea symbol not loaded Which version of VirtualGL? That is literally the most important detail to include in any bug report. Also, if you're observing that '-c proxy' performs better than the default '-c jpeg', then something is terribly wrong. "Proxy mode" is intended for X proxies, e.g. TurboVNC. It sends the images uncompressed through the X11 protocol, which means that, even on gigabit, the most you'll see is 30 Megapixels/sec (JPEG can easily achieve twice that on a 100 Mbit network.) Also, just to clarify, '-c proxy' fails only with Cygwin but works with TurboVNC? Definitely something amiss there as well. You're going to need to provide a lot more details before I can even begin to figure out what's going on. On 9/3/15 2:28 PM, Michael Mirsky wrote: > Hello, > > I’m new to VirtualGL and I’ve been testing it with my Qt5 app. For the > most part, it works flawlessly! However, I have run into one issue. > Specifically, my build of VirtualGL fails with the following error if > I try to launch my app with the “-c proxy” compression option: > > [VGL] ERROR: in FBX— > > [VGL] 510: [FBX] ERROR: XCopyArea symbol not loaded > > Any ideas of what this error means or what I might have missed during > compilation? Running with “-c rgb” or the default works. > > I first tested with the “official” VirtualGL binary package, and > vglrun with the “-c proxy” option performs with the least lag. Thus, > it would be nice to combine that with the xcb interposer so that resize works. > > As some background, my VirtualGL server is running on Linux (RHEL6) > and my client is Windows with Cygwin\X. I’ve tested using TurboVNC and > that works great, but I’d prefer to get Cygwin\X to work if possible. ------------------------------------------------------------------------------ Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users ------------------------------------------------------------------------------ Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
