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 to solicit opinions from the community, in case there might
> be a better approach than the one I took. I'll list the features below:
>
Just some quick comments from me based on a casual read through this.
> (1) Lossless Refresh (LR) -- this is a non-disruptive modification to
> the client. It's simply a button (or a menu option) on the TigerVNC
> Viewer GUI that causes it to send a full framebuffer update request to
> the server without JPEG encoding. This is used by people who are doing
> image quality-sensitive work who want to ensure that they are looking at
> a mathematically lossless copy of the current screen image (for
> instance, in medical visualization, this is important.) It's also used
> by people who are connecting via slow networks. They can use a low
> quality setting for most work, then request a lossless copy whenever
> they are done manipulating the model and want to stare at it for a while.
Nothing really controversial about this one. The only downside is UI
clutter, but I don't see it as a major issue here.
> (2) Automatic Lossless Refresh (ALR) -- This feature is similar to LR
> except that, as the name implies, it's automatic. As currently
> implemented, it is driven by the server rather than the client. When
> the user starts the VNC server, they can specify -alr {t}, where {t} is
> the number of seconds (floating point.) The server analyzes the
> outgoing image stream and maintains a region consisting of all JPEG
> tiles sent since the last lossless refresh. If {t} seconds elapse with
> no updates being sent, then the server automatically sends a new update
> consisting of a lossless copy of the lossy region.
I'd like to believe this could be done in a way where it could always
be turned on, or at least on by default. I didn't get the impression
that any of the problems you listed would prevent that?
>
> Problems:
> -- This is currently implemented as a separate thread, which means
> introducing a dependency on libpthread in Xvnc. Not sure how people
> feel about that.
Not good. As you've mentioned, threading is rather error prone and
getting all corner cases covered is generally an uphill battle.
Why does this require a thread? Don't we already have timers for the
deferred update thing. Couldn't this be handled in a similar manner? If
not, wouldn't it be feasible to add a sufficient timer mechanism?
> -- As implemented in TurboVNC, ALR defaults to only monitoring the
> regions that are drawn using X[Shm]PutImage() (but this behavior can be
> overridden with an environment variable.) Limiting it to PutImage
> requests is mainly done to avoid the "blinking cursor phenomenon"--
> whereby a console window or some other 2D application uses XCopyArea()
> to repeatedly update a very small region of the display, and this
> repeated update keeps resetting the ALR timer so that the ALR is never
> sent. I've observed some ill-behaved window managers that will
> continuously update their status icons using XCopyArea(), which also
> causes the ALR never to be sent unless the ALR-eligible regions are
> limited to the regions drawn using PutImage operations.
The timer might have to be some combination of the oldest event and the
newest. I don't think this is insurmountable and we can experiment with
this going forward, provided that the triggering logic is well
contained.
It might also be worth considering updating parts of the screen, and
not all of it. After all, we're sending a better quality version of
what's already on the screen, so there should be no risk of tearing
caused by partial updates. This would also mitigate issues with the
lossless update introducing latency because it being much larger than
the lossy one.
> We've been discussing in the TurboVNC community the feasibility of
> making ALR a client-side feature.
I'd rather not go down this path. IMO we should have as much of the
encoding logic in the server as possible. It generally has the best
view of things, and often more CPU to spend making the best decision.
> (3) Continuous Updates (CU)
Yay! This, and the lack of caching, are the two biggest problems with
the RFB protocol. It would be a massive improvement if this could be
solved.
> CU takes advantage of the RFB Continuous
> Updates extension (this is a registered extension, not something we made
> up ourselves.)
Interesting. Do you have some reference documentation for this? There
are a lot of annoying corner cases with regard to synchronising with
other RFB messages. I'm interested in seeing how that is dealt with.
There are also the flow/congestion control issues.
> There are obvious problems with this whenever collaboration is enabled.
> CU causes all clients to be "lock-stepped" to the same frame rate (see
> general musings below.)
Is this an inherent problem or something we can work around?
> There is also a lot of confusion among users as
> to when to use it and when not to.
I think this is another feature that we should be able to make good
enough to always have on.
> (4) Multi-threaded compression/decompression
Given the way processors are evolving, this is probably a good idea. As
before though, threading is a source of a lot of problems. It is
probably more contained in this case though and less risk.
Have you looked at using OpenMP? It looks like it would be a rather
good fit for something like this, and most major compilers support it.
I think it would be a great help in avoiding thred issues.
> ... a lot of esoteric performance behavior could be eliminated
> simply by implementing a proper frame spoiling mechanism. This would
> eliminate the need for the CU feature as well.
Howso? Without CU, then we would still be limited to one update per
round trip.
> A proper frame spoiling mechanism would have a separate image queue and
> dispatch thread for each connected client, so that all of the clients
> could be driven at their own frame rates without requiring a
> client-driven protocol or a deferred update timer.
Did you check that the RealVNC 4 code didn't really have this? I seem
to recall that it creates a separate object for each client, and it is
within that object it stores client state (like what needs to be
updated). It is not threaded (although I seem to recall some support
for that as well), but it should already server each client at the rate
it sees update requests?
> 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 having one client updating at 30 Hz and one at 10 Hz should
not be an issue. It's just that the second client will see the
aggregate of three changes (from the first's point of view).
Rgds
--
Pierre Ossman OpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio AB Web: http://www.cendio.com
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
