Mailing List Archive

On Mon, Aug 24, 2009 at 11:32:05PM -0500, DRC wrote:
> 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 these official so we could use them in TigerVNC as well:
>
>
> Special encoding numbers:
> -------------------------
> 0xFFFFFE00 .. 0xFFFFFE64 -- fine-grained quality level (0-100 scale)
>
> rfbEncodingFineQualityLevel0 0xFFFFFE00
> rfbEncodingFineQualityLevel100 0xFFFFFE64
>
> 0xFFFFFD00 .. 0xFFFFFD05 -- subsampling level, for image compression
> methods that support it
>
> rfbEncodingSubsamp1X 0xFFFFFD00
> rfbEncodingSubsamp4X 0xFFFFFD01
> rfbEncodingSubsamp2X 0xFFFFFD02
> rfbEncodingSubsampGray 0xFFFFFD03
> rfbEncodingSubsamp8X 0xFFFFFD04
> rfbEncodingSubsamp16X 0xFFFFFD05
>
> (NOTE: these are out of order for historical reasons.)
>
> sig_rfbEncodingFineQualityLevel "FINEQLVL"
> sig_rfbEncodingSubsampLevel "SSAMPLVL"

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 encoding for each
quality level. We should include image quality control as part of the
JPEG encoding. I know it will take more time than straightforward port
from TurboVNC. What do you think about that?

>
> Tight Encoding:
> ---------------
>
> Propose to extend the compression control byte for Tight encoding as
> follows:

Unfortunately I don't think we can extend the Tight encoding. You
should discuss this change with Constantin.

>
> rfbTightNoZlib 0x0A
>
> The first byte of each Tight-encoded rectangle is a "compression control
> byte". Its format is as follows (bit 0 is the least significant one):
>
> bit 0: if 1, then compression stream 0 should be reset;
> bit 1: if 1, then compression stream 1 should be reset;
> bit 2: if 1, then compression stream 2 should be reset;
> bit 3: if 1, then compression stream 3 should be reset;
> bits 7-4: if 1000 (0x08), then the compression type is "fill",
> if 1001 (0x09), then the compression type is "jpeg",
>
> (*** NEW ***) if 1010 (0x0A), then the compression type is
> "basic" and no Zlib compression was used (*** NEW ***)
>
> if 0xxx, then the compression type is "basic" and Zlib
> compression was used,
> values greater than 1010 are not valid.
>
> If the compression type is "basic" and Zlib compression was used, then
> bits 5..4 of the compression control byte specify the following:
>
> bits 5-4: decimal representation is the index of a particular zlib
> stream which should be used for decompressing the data.
>
> Bit 6 of the compression control byte specifies the following,
> regardless of whether Zlib compression was used:
>
> bit 6: if 1, then a "filter id" byte is following this byte.
> ...

Regards, Adam

--
Adam Tkac, Red Hat, Inc.

_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

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 encoding for each
> quality level. We should include image quality control as part of the
> JPEG encoding. I know it will take more time than straightforward port
> from TurboVNC. What do you think about that?
>
These extensions are not necessarily specific to JPEG. They could be
used by other encoding methods that need fine-grained quality control.
I'm not sure I understand what you're proposing. I understand the
notion of creating a separate rfbEncodingJpeg method, but why does that
preclude what I'm proposing above? We still need to define a way for
the client to request a fine-grained quality change from the server.
Please provide a specific example of how you would propose to do that.

What I'm proposing is very similar to how rfbEncodingCompressLevelX
works currently. The client can request a specific compress level or
quality level in addition to specifying the encoding method.

> 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 official registry for RFB extensions, then why am I
bothering to go through this process?

If we can't extend Tight encoding, then my counter-proposal would be to
create a new rfbEncodingTightNoZlib method.


_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

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 document it
> > in the RFB protocol we should not create separate encoding for each
> > quality level. We should include image quality control as part of the
> > JPEG encoding. I know it will take more time than straightforward port
> > from TurboVNC. What do you think about that?
> >
> These extensions are not necessarily specific to JPEG. They could be
> used by other encoding methods that need fine-grained quality control.

Yeah, you are absolutely correct. But I'm not sure that all future
encodings will use same image quality schema as JPEG. If we add new
pseudo encodings to control the JPEG specific quality levels I think
we polute "encoding namespace".

> I'm not sure I understand what you're proposing. I understand the
> notion of creating a separate rfbEncodingJpeg method, but why does that
> preclude what I'm proposing above? We still need to define a way for
> the client to request a fine-grained quality change from the server.
> Please provide a specific example of how you would propose to do that.

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->server JPEG encoding is supported
server->client Framebuffer update encoded in JPEG
client->server Change quality to level X

With this approach you pollute "encodings namespace" with 100 new
encodings which should be bound to the JPEG encoding.

I propose different approach. JPEG client->server message will include
information about quality level. Main difference with my and your
proposals is that you've added 100 new encodings but I've added only
one JPEG encoding.

> What I'm proposing is very similar to how rfbEncodingCompressLevelX
> works currently. The client can request a specific compress level or
> quality level in addition to specifying the encoding method.
>
> > 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 official registry for RFB extensions, then why am I
> bothering to go through this process?

Well, the place is probably here and also on
https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto.

> If we can't extend Tight encoding, then my counter-proposal would be to
> create a new rfbEncodingTightNoZlib method.

The Tight encoding is tricky. It is `owned` by Constantin Kaplinsky
and the TightVNC project. I think we should not touch it unless
Constantin approves the change. Btw could I ask you why would you like
to create such encoding?

Regards, Adam

--
Adam Tkac, Red Hat, Inc.

_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

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 official registry for RFB extensions, then why am I
> bothering to go through this process?

The VNC software and RFB protocol are maintained by RealVNC Ltd, including allocation of numbers for new encodings, etc. I've passed on your request for allocation of some encoding numbers for your project, and we'll get back to you shortly.

> If we can't extend Tight encoding, then my counter-proposal would be to
> create a new rfbEncodingTightNoZlib method.

The Tight encoding was designed by Const Kaplinsky as part of the TightVNC project - I think Adam is simply suggesting that any proposed changes to that encoding need to be OK'd by Const, rather than break compatibility with his project.

HTH,

--
Wez @ RealVNC Ltd



_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

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->server JPEG encoding is supported
> server->client Framebuffer update encoded in JPEG
> client->server Change quality to level X
>
> With this approach you pollute "encodings namespace" with 100 new
> encodings which should be bound to the JPEG encoding.
> I propose different approach. JPEG client->server message will include
> information about quality level. Main difference with my and your
> proposals is that you've added 100 new encodings but I've added only
> one JPEG encoding.
>
Won't that break compatibility with TurboVNC and TightVNC? Or was the
intent to keep the existing Tight JPEG mechanism as well and just use
the new JPEG encoding only if both client and server support it? There
are very real and provable advantages to the Tight scheme of using JPEG
for high-color-depth tiles and paletted encoding for low-color-depth
tiles. We don't ever want to use just pure JPEG encoding for the whole
framebuffer. However, my understanding of what is being proposed by you
and Pierre and others is that we want to eventually be able to compress
individual tiles using different encodings and deprecate the Tight
mechanism of using subencodings.

I'm less concerned with being able to use, for instance, a TigerVNC
viewer to send fine-grained quality updates to a TurboVNC server,
because we aren't planning to expose the fine-grained quality controls
anyhow. Their main purpose is so that the automatic quality adjustment
code can "zero in" on an appropriate quality that meets the desired
bandwidth/performance constraints, so this stuff will all be taking
place behind the scenes.

However, the counter arguments I would make are:

(1) It's not like we're running out of encoding numbers or anything. We
have billions of them available, so "encodings namespace pollution" is
perhaps overstating the issue a bit.
(2) Tight quality and compress level are already set using the above
mechanism.
(3) TurboVNC has been using these encodings unofficially for five
years. It would be nice to make them official, irrespective of whether
or not we replace them with a new mechanism, because it would prevent
anyone else from trying to use them and provide a bridge for us until we
can implement our long-term scheme.

>> If we can't extend Tight encoding, then my counter-proposal would be to
>> create a new rfbEncodingTightNoZlib method.
>>
>
> The Tight encoding is tricky. It is `owned` by Constantin Kaplinsky
> and the TightVNC project. I think we should not touch it unless
> Constantin approves the change. Btw could I ask you why would you like
> to create such encoding?
>
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 Hextile encoding
and is useful in several scenarios, including connecting to a local VNC
server, re-compressing and redisplaying the output of vncviewer, or in
situations in which you simply have a lot of network bandwidth and want
to conserve server CPU time as much as possible.

In order to reduce CPU time, it is necessary to bypass Zlib encoding,
because Zlib with compress level 0 still has a lot of CPU overhead, even
though it isn't actually compressing. An alternative proposal was to
modify Zlib to fix this issue, but it's a very old code, and I'm dubious
as to our ability to get changes to it put back into the master code base.

However, if we ultimately implemented a higher level sort of scheme
whereby individual tiles could use different encodings, then
implementing the above would be a simple matter of assigning Raw
encoding to some tiles and Tight encoding (or a new, separate paletted
encoding scheme) to others, based on their color counts.

rfbEncodingTightNoZlib was an admitted hack, and since it wasn't
introduced until TurboVNC 0.5, there is much less of a legacy concern here.


_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

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 Hextile encoding
[snip]

FYI, this sounds very similar to what the standard TRLE encoding already does.

Cheers,

--
Wez @ RealVNC Ltd





_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

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:
> >
> > client->server JPEG encoding is supported
> > server->client Framebuffer update encoded in JPEG
> > client->server Change quality to level X
> >
> > With this approach you pollute "encodings namespace" with 100 new
> > encodings which should be bound to the JPEG encoding.
> > I propose different approach. JPEG client->server message will include
> > information about quality level. Main difference with my and your
> > proposals is that you've added 100 new encodings but I've added only
> > one JPEG encoding.
> >
> Won't that break compatibility with TurboVNC and TightVNC? Or was the
> intent to keep the existing Tight JPEG mechanism as well and just use
> the new JPEG encoding only if both client and server support it? There
> are very real and provable advantages to the Tight scheme of using JPEG
> for high-color-depth tiles and paletted encoding for low-color-depth
> tiles. We don't ever want to use just pure JPEG encoding for the whole
> framebuffer. However, my understanding of what is being proposed by you
> and Pierre and others is that we want to eventually be able to compress
> individual tiles using different encodings and deprecate the Tight
> mechanism of using subencodings.

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 really don't like such approach because it might end with
crippled and badly designed protocol.

I would really like to see the Tight encoding and sub-encodings
mechanism deprecated. But it won't happen soon.

> I'm less concerned with being able to use, for instance, a TigerVNC
> viewer to send fine-grained quality updates to a TurboVNC server,
> because we aren't planning to expose the fine-grained quality controls
> anyhow. Their main purpose is so that the automatic quality adjustment
> code can "zero in" on an appropriate quality that meets the desired
> bandwidth/performance constraints, so this stuff will all be taking
> place behind the scenes.
>
> However, the counter arguments I would make are:
>
> (1) It's not like we're running out of encoding numbers or anything. We
> have billions of them available, so "encodings namespace pollution" is
> perhaps overstating the issue a bit.

The number of possible encodings is not a limitation. I would like to
point that adding stuff, which is _very_ closely bounded to the existing
encoding (Tight encoding with JPEG subencoding in this case), as a
separate encodings is not a good idea. In my opinion the image quality
related extensions should be delayed till new JPEG encoding (not
the Tight->JPEG encoding) gets created or add image quality related
stuff as Tight subencoding.

> (2) Tight quality and compress level are already set using the above
> mechanism.

Yes, of course, because the Tight encoding is the protocol inside RFB
protocol.

> (3) TurboVNC has been using these encodings unofficially for five
> years. It would be nice to make them official, irrespective of whether
> or not we replace them with a new mechanism, because it would prevent
> anyone else from trying to use them and provide a bridge for us until we
> can implement our long-term scheme.

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?

> >> If we can't extend Tight encoding, then my counter-proposal would be to
> >> create a new rfbEncodingTightNoZlib method.
> >>
> >
> > The Tight encoding is tricky. It is `owned` by Constantin Kaplinsky
> > and the TightVNC project. I think we should not touch it unless
> > Constantin approves the change. Btw could I ask you why would you like
> > to create such encoding?
> >
> 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 Hextile encoding
> and is useful in several scenarios, including connecting to a local VNC
> server, re-compressing and redisplaying the output of vncviewer, or in
> situations in which you simply have a lot of network bandwidth and want
> to conserve server CPU time as much as possible.
>
> In order to reduce CPU time, it is necessary to bypass Zlib encoding,
> because Zlib with compress level 0 still has a lot of CPU overhead, even
> though it isn't actually compressing. An alternative proposal was to
> modify Zlib to fix this issue, but it's a very old code, and I'm dubious
> as to our ability to get changes to it put back into the master code base.
>
> However, if we ultimately implemented a higher level sort of scheme
> whereby individual tiles could use different encodings, then
> implementing the above would be a simple matter of assigning Raw
> encoding to some tiles and Tight encoding (or a new, separate paletted
> encoding scheme) to others, based on their color counts.

AFAIK individual tiles could already use different encodings and I
think this approach should be preferred.

> rfbEncodingTightNoZlib was an admitted hack, and since it wasn't
> introduced until TurboVNC 0.5, there is much less of a legacy concern here.

Then you can probably mail to Constantin and tell him you've extended
the Tight extension.

Regards, Adam

--
Adam Tkac, Red Hat, Inc.

_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

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 really don't like such approach because it might end with
> crippled and badly designed protocol.
[snip]

FWIW, I think you're confusing the Tight encoding, which is just another image-encoding scheme, with the Tight pseudo-Security-Type, which is used to indicate that the two parties support custom protocol elements from the TightVNC project.

HTH,

--
Wez @ RealVNC Ltd





_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

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 particular, was that the
tile sizes were too small (16x16), which caused the protocol to be very
latency sensitive, even on LANs. The TurboVNC Lossless-Tight protocol
tries to use 64 kpixel tiles, in general. And of course, Raw is
inefficient because it sends way more data than necessary. The basic
goal with Lossless-Tight was to reduce the CPU usage to almost nothing
(use very little additional CPU over Raw) but provide a significant
speedup for typical 3D apps (CAD applications, for instance, are never
going to use very many colors.)


_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

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.


_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

Hello Darrell, Adam,

>>>>> DRC wrote:

>> 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 official registry for RFB extensions, then why am I
> bothering to go through this process?

You should extend existing encodings only in a way that would not break
interoperability with existing clients and servers. E.g. you send some
special pseudo-encoding code in SetEncodings, then the server may start
using your particular extension to the Tight encoding. Note that such
special pseudo-encoding code should be registered in the RealVNC's
official RFB specification.

As for extending the Tight encoding, I'd prefer that it would not be
called "Tight" after any extensions or other changes have been
introduced. That's just to prevent unnecessary confusion.

--
With Best Wishes,
Constantin


_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

Hello Adam,

>>>>> Adam Tkac wrote:

> 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 really don't like such approach because it might end with
> crippled and badly designed protocol.

You are seriously mistaken. Tight encoding is just an encoding, not a
"protocol inside protocol". It does not allow to encapsulate other
encodings. Indeed, Tight encoding has subencodings (e.g. JPEG) but the
set of subencodings is fixed and they are integral parts of the Tight
encoding and just allow to encode data in different ways depending on
the statistical properties of that data.

TightVNC does not include anything like "FTP-like transfer related
encodings". File transfers are implemented via TightVNC extensions to
the RFB protocol, they do not use any encodings, they use new protocol
messages.

--
With Best Wishes,
Constantin

_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

On Sat, 05 Sep 2009 13:05:39 +0700
Constantin Kaplinsky <const@tightvnc.com> wrote:

> Hello Adam,
>
> >>>>> Adam Tkac wrote:
>
> > 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 really don't like such approach because it might end with
> > crippled and badly designed protocol.
>
> You are seriously mistaken. Tight encoding is just an encoding, not a
> "protocol inside protocol". It does not allow to encapsulate other
> encodings. Indeed, Tight encoding has subencodings (e.g. JPEG) but the
> set of subencodings is fixed and they are integral parts of the Tight
> encoding and just allow to encode data in different ways depending on
> the statistical properties of that data.
>

I think Adam's point is precisely that Tight has sub-encodings. The
server could just as well have chosen between several "normal"
encodings based on the data. Subencodings are not needed for that. In
essence Tight layers another encoding system on top of the existing
one.

(And they're not really fixed either as the JPEG encoding is not used
until the server has seen a "Quality" encoding.)

Rgds
--
Pierre Ossman OpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio AB Web: http://www.cendio.com

Hi DRC,

[snip]
> 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?
[snip]

Hmmm. It's in the IETF Draft, but doesn't seem to have made it into the current RFB 3.8 protocol spec document.

> One of the problems I ran into with Hextile, in particular, was that
> the
> tile sizes were too small (16x16), which caused the protocol to be very
> latency sensitive, even on LANs
[snip]

I'm not sure I understand why the tile size affects latency-sensitivity, unless you're flushing each tile to the TCP stack for transmission separately, or something. Can you elaborate?

Regards,

--
Wez @ RealVNC Ltd







_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

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" <jnw@realvnc.com> wrote
> I'm not sure I understand why the tile size affects latency-
> sensitivity, unless you're flushing each tile to the TCP stack for
> transmission separately, or something. Can you elaborate?

_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

Hi DRC,

It makes sense for tile size to affect performance in a *bandwidth* dependent way, but not for it to affect latency sensitivity. That said, I gather you're working on a project based on the old VNC 3.3.x codebase, so it may well be that there's some I/O scheduling issue in that.

HTH,

--
Wez @ RealVNC Ltd



> -----Original Message-----
> From: DRC [mailto:drcommander@gmail.com] On Behalf Of DRC
> Sent: 07 September 2009 16:06
> To: <james.weatherall@realvnc.com>
> Cc: <vnc-list@realvnc.com>
> Subject: Re: Extensions for fine-grained image quality control
>
> 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" <jnw@realvnc.com> wrote
> > I'm not sure I understand why the tile size affects latency-
> > sensitivity, unless you're flushing each tile to the TCP stack for
> > transmission separately, or something. Can you elaborate?


_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list