>
> >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.
I have observed the black notch issue with the java viewer previously as
well. If the call to "paintImmediately" in DesktopWindow.updateWindow is
replaced with "repaint" these notches are observed. Using repaint rather
than paintImmediately allows swing to defer drawing until it can collapse
multiple updates into a single paint operation. I'm not sure how Fltk
handles painting, but if it's deferring the actual screen updates in some
similar manner then that could be the culprit.
-brian
------------------------------------------------------------------------------
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
