On Tue, 30 Aug 2011 09:41:56 -0600
DRC dcomman...@users.sourceforge.net wrote:
I don't follow. ALR is only ever relevant for one frame at a time. It
won't ever be sent unless the connection is completely idle for a
specified period of time, so it can't be sent on multiple frames because
On 9/1/11 3:34 AM, Pierre Ossman wrote:
I don't follow. ALR is only ever relevant for one frame at a time. It
won't ever be sent unless the connection is completely idle for a
specified period of time, so it can't be sent on multiple frames because
there aren't multiple frames for it to
On Wed, 13 Jul 2011 06:19:16 -0500
DRC dcomman...@users.sourceforge.net wrote:
On 7/13/11 3:49 AM, Pierre Ossman wrote:
(2) Automatic Lossless Refresh (ALR) -- This feature is similar to LR
I'd like to believe this could be done in a way where it could always
be turned on, or at least
On 8/30/11 6:06 AM, Pierre Ossman wrote:
It already does this. Only the tiles that were previously sent with
lossy compression are re-sent during an ALR.
Yes, but I meant that we could also split those parts into smaller
pieces. E.g. say that 50% of the screen is lossy. But that's a lot of
On 7/13/11 3:49 AM, Pierre Ossman wrote:
This is not only
disruptive but possibly even violates the fundamental nature of the RFB
protocol,
What makes you say that? The protocol doesn't mention anything about
update rates, only that each update should represent a full screen
change. So
On Tue, 12 Jul 2011 20:48:19 -0500
DRC dcomman...@users.sourceforge.net wrote:
Cendio has asked me to investigate, over the coming months, the
possibility of merging in some of the more advanced features from
TurboVNC into TigerVNC, but some of these are potentially disruptive,
and I wanted
Cendio has asked me to investigate, over the coming months, the
possibility of merging in some of the more advanced features from
TurboVNC into TigerVNC, but some of these are potentially disruptive,
and I wanted to solicit opinions from the community, in case there might
be a better approach than
