At 2011-09-05 16:55, DRC wrote:
On Sep 5, 2011, at 6:21 AM, Csillag Kristof <[email protected]
<mailto:[email protected]>> wrote:
Hi,
I am still evaluating TurboVNC and TigerVNC for a project.
There are a few special requirements, and I would like to ask you
whether I can fulfill them with these tools.
1. I need a way to influence the compression settings and/or to request
a lossless refresh from the X client (application) side. I understand
that this is not easy with the current architecture, because connection
settings are stored on a per-client basis, however, in our case, tI am
willink here is always exactly one client. I understand that currently,
this is not supported, but I am willing to implement it, if possible.
What I would need to know (for now) is this: which component, and which
layer is making the decisions about the currently used compression? If
it's the server-side, then I can add the framework to control this from
the X client (the actual application). If it's decided on the client
side, can the server-side influence this somehow
Theoretically, if you were willing to force the same compression
settings upon all clients,
We will have only one client, so that's not a problem.
then it might be possible to extend the VNC X11 extension with an
additional function that allows for setting the compression parameters.
OK, we might try to do that later.
However, the problem is that the compression parameters are very
specific to the type of encoding being used. You couldn't, for
instance, force a client to receive JPEG, because you have no idea
whether the client even supports Tight encoding.
We can assure that all clients are using the latest version of turbovnc
/ tightvnc client.
Perhaps if you explain more about why you want to do this, we can
propose a cleaner solution.
We are required to configure the compression level according to some
central policies, dictated by other requirements.
There are situations when we absolutely need to do lossless encoding
(whatever the performance is), and in other cases,
we would like to configure the lossy compression level according to some
external bandwidth usage policies.
This all must be handled on the server side, in a centralized manner.
(And run-time changes are required, too, because the type of content to
transfer might change; some needs lossless quality, and some can do with
lossy, so we must be able to change it, from the application side.)
2. I need a way to guarantee that a given drawing operation (XPutImage)
is represented on the client side, before continuing to draw something
over it. Completion should not be signaled until the client has actually
received the data. (Again, we have only one client, so no need to worry
about several components.) How difficult would it be to implement this?
This is implemented in the TurboVNC CVS head by using an undocumented
extension to RFB called "continuous updates."
Great.
It still needs some tweaking, however. We are still discussing how
best to make TigerVNC do something similar. To be clear, with CU, the
XPutImage() calls become "effectively" synchronous, but there is still
no way to truly guarantee that the client has received the data before
returning.
OK, so what is it that we _can_ guarantee? What is the XPutImage
synchronized to, then?
Again, what are you trying to accomplish? Maybe there's a better way.
We need to assure that every single frame the application draws reaches
the client.
We need to "slow down" the server to wait for everything to reach the
client.
The client must see every single frame, so that we can be sure that the
viewer does not miss anything that turns up on a frame, but disappears
on the next.
(It's a medical application, so it's imperative that this is strictly
enforced.)
3. We are going to transfer multi-megapixel images with a high
frame-rate. What do we need to do to enable multi-thread jpeg
compression with libjpeg-turbo?
TurboVNC does multi-threaded compression.
Is this implemented in the libjepg-turbo codec, all hidden behind the
the standard libjpeg API?
Do we need to do something to configure/enable this, or is this on
automatically?
However, multi-threaded decompression is not yet implemented--
basically, the company that was sponsoring the improvement backed out
before I could finish it.
That's a pity.
Multi-threading the compressor is of only limited usefulness without
multi-threading the decompressor as well.
Sure, but still, the server side tends to have more cores than the
client side, so it's still a gain..
We are still discussing how best to implement multithreading In TigerVNC.
So is there a need to support this on the tigervnc/turbovnc level, too?
Can not the jpeg codec handle this properly on it's own?
Thank you for your help:
Kristof
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Tigervnc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tigervnc-users
