Bug Tracker item #3531487, was opened at 2012-06-01 22:33 Message generated for change (Comment added) made by dcommander You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3531487&group_id=254363
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: FLTK viewer Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: D. R. Commander (dcommander) Assigned to: Pierre Ossman (ossman_) Summary: Double buffering doesn't work properly in new viewer Initial Comment: Double buffering doesn't seem to work properly with the FLTK viewer, nor the latest Java viewer in trunk (most likely because the Java viewer is borrowing the FLTK viewer's logic.) The easiest way I've found to repro this is to run GLXspheres in VirtualGL and add 200 ms of artificial latency to the server: sudo tc qdisc add dev eth0 root netem delay 200ms vglrun /opt/VirtualGL/bin/glxspheres -i Rotate the spheres, then stop, then start rotating them again. You should observe "notches" disappear from the upper spheres, most likely due to some of the solid rectangles not being rendered prior to the frame advancing. I also observe frequent tearing artifacts, whereby only half of the frame is drawn before it advances. I observe this most readily on a RHEL 6 client (nVidia GeForce) connecting to a RHEL 5 server, but I also observe it to a lesser degree when using my Mac Mini as a client. ---------------------------------------------------------------------- >Comment By: D. R. Commander (dcommander) Date: 2012-06-02 01:10 Message: Further investigation shows that at least part of the problem is that I'm hitting the update timeout. If, for instance, I comment out self->updateWindow() in Viewport::handleUpdateTimeout(), double buffering works properly, and I seem to experience no ill effects. However, I haven't examined the code closely to see why that timer is there. What seems to happen is that, whenever a rectangle is damaged, it triggers a timeout, and if the rectangle isn't drawn within 1/2 second, it gets drawn anyway, so if the frame is really slow to transmit, it will not be double buffered. The black notch issue appears to be independent of the update timeout, so that issue may be a Tight decoder bug or something like that. ---------------------------------------------------------------------- Comment By: D. R. Commander (dcommander) Date: 2012-06-01 22:38 Message: I should also add that this is reproducible when using the FLTK viewer with either the TigerVNC 1.2.0 server or the TurboVNC server, which would seem to eliminate the flow-control extensions as a cause (since TurboVNC hasn't implemented them yet.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126848&aid=3531487&group_id=254363 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
