Whew. So, for starters, I confirmed the behavior you're observing, but to figure out why it's happening required trolling the commit logs from a few years back.
ALR used to be implemented using a second thread, which would wake up every 100 milliseconds, iterate through all of the active client connections, and send an ALR for those clients who were due for one (and also subject to the standard conditions for an ALR-- that is, lossy images needed to have been sent to the client since the last ALR, and those images needed to have been sent as a result of an "ALR-eligible" X drawing function.) This approach took a lot of debugging to get right, because we had to introduce a ton of mutexes to prevent, among other things, an ALR being sent at the same time as a "normal" update. One of the synchronization mechanisms was a variable called "firstUpdate" that was set to TRUE whenever the first framebuffer update was sent to the client, and the ALR thread would not send an ALR until this variable was TRUE for the client in question. I honestly can't remember what specific bug that fixed, and there is no record of it, since the first commit of the ALR feature already contained the variable. Anyhow, it appears that somehow the usage of firstUpdate got perverted over the years, in the process of fixing various issues with ALR and ultimately eliminating the use of threads in that feature. I think that, ultimately, the variable became vestigial but was never removed, and now what's happening is that it causes the first update to always be eligible for ALR, regardless of whether it meets the criteria set in TVNC_ALRALL. I've checked in a patch to trunk, but there are some other things I need to look into before generating a new pre-release build, so for now, you'll have to build from source if you want to try it out. On 10/4/13 4:24 PM, Kevin Van Workum wrote: > OK, that makes sense. But then why do I get that 1 initial refresh? > > On Fri, Oct 4, 2013 at 5:08 PM, DRC <dcomman...@users.sourceforge.net> wrote: >> The default is for ALR to affect only PutImage operations, which is what VGL >> uses to draw images. Many 2D apps use other methods to draw images, like X >> Render or CopyArea, that won't be subject to ALR unless you set TVNC_ALRALL. >> The docs go into more detail. ALR is really targeted at 3D apps. >> >>> On Oct 4, 2013, at 10:11 AM, Kevin Van Workum <v...@sabalcore.com> wrote: >>> >>> There was no blinking cursor. Setting TVNC_ALRALL=1 makes the refresh >>> work. So maybe it's not a bug. >>> >>>> On Fri, Oct 4, 2013 at 10:41 AM, Kevin Van Workum <v...@sabalcore.com> >>>> wrote: >>>> I'm having trouble with the -alr option to Xvnc. I start the server with: >>>> >>>> $ /opt/TurboVNC/bin/vncserver -alr 5 >>>> >>>> Then connect with: >>>> >>>> /opt/TurboVNC/bin/vncviewer -Subsampling=gray -Quality=10 host:6 >>>> >>>> When my desktop appears, it is using the specified Subsampling and >>>> Quality. Then, without interacting with the desktop, within 5 seconds >>>> I get a lossless refresh as expected. But if I then interact with the >>>> desktop a bit, I do not get a refresh after 5 seconds of inactivity. >>>> >>>> Kevin >>>> >>>> -- >>>> Kevin Van Workum, PhD >>>> Sabalcore Computing Inc. >>>> "Where Data Becomes Discovery" >>>> http://www.sabalcore.com >>>> 877-492-8027 ext. 11 >>> >>> >>> >>> -- >>> Kevin Van Workum, PhD >>> Sabalcore Computing Inc. >>> "Where Data Becomes Discovery" >>> http://www.sabalcore.com >>> 877-492-8027 ext. 11 >>> >>> -- >>> >>> >>> ------------------------------------------------------------------------------ >>> October Webinars: Code for Performance >>> Free Intel webinars can help you accelerate application performance. >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >>> from >>> the latest Intel processors and coprocessors. See abstracts and register > >>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> VirtualGL-Users mailing list >>> VirtualGL-Users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >> the latest Intel processors and coprocessors. See abstracts and register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >> _______________________________________________ >> VirtualGL-Users mailing list >> VirtualGL-Users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
