It's not a false alarm. 2.4.80 = 2.5 alpha, so that means there's a bug in the evolving VGL 2.5 code that needs to be fixed before it goes into beta. That's why I needed to know which version you were using. I strongly suspected that you were using the 2.5 alpha version, which has a lot of changes to how symbols are loaded. You probably got the tarball from our pre-releases page.
I would not expect there to be much noticeable difference in the three VGL compression options within the TurboVNC environment, because TurboVNC is actually doing the compression. When you use -c jpeg in TurboVNC, you are just wasting CPU cycles, because VirtualGL is compressing the images, vglclient is decompressing them, and TurboVNC is compressing them again. But it still doesn't explain why JPEG would be slower in Cygwin. That definitely should not be the case. I will investigate the bug in 2.5 alpha. On 9/3/15 5:33 PM, Michael Mirsky wrote: > 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 > ------------------------------------------------------------------------------ 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
