On Wed, Dec 12, 2007 at 01:50:38PM -0000, James Weatherall wrote: > Hi Anon, > > This is a know limitation of the Refresh Screen option in VNC Free Edition & > VNC Free Edition-based software, which isn't "safe" to use if the VNC Viewer > might be changing pixel format at a later point.
Nice to see it confirmed, I have been thinking about this for a while but never got around to formulating it in an email. Also, you seem to hint that this isn't a problem in the closed sourced versions, can you enlighten us as to how the problem was resolved, if it has indeed been resolved? > You shouldn't need to use > Refresh Screen, in general. Well, that puts limitations on the client implementation. Just as an example, imagine a client that draws in a framebuffer and that the user changes screen resolution (or that some other application "borrows" the framebuffer). The client has only one thing to do when it wants to refill the framebuffer, if it is not allowed to send a full refresh request: keep a private copy. That isn't too nice, given this is a thin client protocol. Oh, right, the client can wait for the next update to be issued as well and then send a full update request, but that can be a loooong wait. Not too nice either... When the solution is a simple as introducing a pseudo-encoding that gets sent (if requested of course) as an empty rect before any rect with the new pixfmt is sent, why not introduce that? That would make the protocol more robust, and is easy to implement. The client has to take care not to have two pixfmt changes on the wire simultaneously though, but that's not too much of a limitation. (Other solutions are of course also possible, this is just the first that came to mind) Cheers, Peter _______________________________________________ VNC-List mailing list [email protected] To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
