I guess I should have really learned by now to stop second guessing myself. Upon further examination, the reason why the firstUpdate mechanism is there is because there may be circumstances under which a user leaves their 3D application running and then reconnects to the TurboVNC Server session, and in that case, the ALR mechanism normally wouldn't be triggered, because no new PutImage() operation has occurred. Thus, I made it so that the first update after a new connection is always ALR-eligible, regardless of the TVNC_ALRALL setting. In short, it was intended behavior.
I did, however, go back and re-evaluate some of the other ALR implementation details, and I found a couple of minor issues that are now fixed in trunk (1.3 evolving): -- When TVNC_ALRALL=0, the intent was for only pixels drawn using PutImage operations to trigger an ALR and to be re-sent in lossless form. TurboVNC 1.2 and prior accomplished the former goal, but whenever a PutImage operation triggered an ALR, all lossy regions of the display would be re-sent, not just the ones that were drawn with PutImage. That has been fixed. -- The destination of a CopyRect operation is now ALR-eligible, if the source was affected by lossy compression (if the source was affected by lossy compression, then the destination will be as well, once the operation completes.) This fixes a few artifacts that would occur when dragging windows. Any feedback is very welcome. > 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. ------------------------------------------------------------------------------ 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=60135991&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
