Hi. I run the VirtualGL Project, which produces a TightVNC derivative
called TurboVNC. I am also involved with the next generation TigerVNC
Project, which aims to replace both. TurboVNC has been unofficially
using the following extensions to the RFB protocol, and I wanted to see
if I could make
Adam Tkac wrote:
> There is a bug report about creation of the separate JPEG encoding -
> http://sourceforge.net/tracker/?func=detail&aid=2674740&group_id=254363&atid=1126849.
>
> If we are really going to create new JPEG encoding and document it
> in the RFB protocol we should not create separate
Adam Tkac wrote:
> If I understand correctly you are proposing separate messages (with
> "messages" I mean multiple rectangles with different encodings) for
> JPEG and quality levels. Communication client<->server will look like:
>
> client->serverJPEG encoding is supported
> server->client
James Weatherall wrote:
> [snip]
>
> FYI, this sounds very similar to what the standard TRLE encoding already does.
>
I haven't seen TRLE and can't seem to find any information on that
protocol. Is it available in a current release of RealVNC?
One of the problems I ran into with Hextile, in pa
Adam Tkac wrote:
> If TurboVNC uses this mechanism long time then it's a good idea to
> prevent someone from using them. But I would like to see a comment
> that those encodings should not be used in new implementations. Is it
> acceptable for you?
>
Yes, that's acceptable.
___
I'm just reporting what I observed. I don't really know the underlying
reasons behind it, either. I see the same effect with the Tight
protocol. I can't get peak performance out of that protocol with tile
sizes less than 64 kpixels.
On Sep 7, 2009, at 8:23 AM, "James Weatherall" wrote
> I'm
