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
On Wed, Sep 02, 2009 at 05:09:44PM -0500, DRC wrote:
> 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 d
Hi DRC,
[snip]
> > Unfortunately I don't think we can extend the Tight encoding. You
> > should discuss this change with Constantin.
> >
> I'm not sure I understand how this works. Can someone enlighten me as
> to how RFB extensions are registered and conflicts are avoided? If
> there is no offi
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
On Thu, Sep 03, 2009 at 06:04:59AM -0500, DRC wrote:
> 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:
> >
> >
Hello again DRC,
[snip]
> It enables a particular lossless mode whereby paletted encoding is used
> for low-color-depth tiles and uncompressed raw pixels are sent for
> high-color-depth tiles. This is used in TurboVNC 0.5 as a much faster
> (and generally lower bandwidth) alternative to Raw and H
Adam,
[snip]
> AFAIK the Tight encoding is a mechanism to encapsulate other
> encodings thus you end with something like a "protocol inside
> protocol" (The Tight encoding already has many sub-encodings like
> FTP-like transfer related encodings and the JPEG encoding as you wrote
> above). I reall
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.
___
