No subject

Quote
The current default method to encode images in NX X sessions is JPEG, with
quality determined according to link settings.

Other available methods are PNG and ZLIB X bitmap compression.

JPEG is a lossy image format.

Most remote display systems cannot generally use JPEG as in these
systems not only images but even generic screen updates, containing
text or other vector graphics, are encoded as bitmaps.

In these systems the use of JPEG would make the resulting output clumsy.

NX, instead, preserves the original X protocol to handle text and graphics
rendering and uses lossy image compression only for X requests carrying
actual bitmap images.
Unquote

This gist of this is they they compress the X message traffic for text,
( mostly by cache hits and differential updates )

which means that the choice of bitmap compression is not going to affect
office work so much, although we both notice that button icons are a bit
blurry.


I haven't changed my view. There isn't much you can do, but you do
 need to set the link type.

1/ Make sure the server is up to the job
2/ Use the fastest link you can - with ssh link encryption you can tell
        the users to use an Internet Cafe instead of a 2M 3G stick
2a/ Don't forget the server end of the link may be loaded up
3/ Select the correct (client) link speed whatever it (actually) is
4/ Minimize traffic, use rootless apps etc
5/ Test it out for your site and applications
6/ Don't tell the users they can tweak things.

We await other users telling us of their experiences !!.

One other thing.

Do you see any content in the client disk cache ??

CB

> 
> Thanks for you attention:
> Toni
> 

--=_alternative 00314BA080257737_=
Content-Type: text/html; charset="US-ASCII"


<br><tt><font size=2>Toni Asensi Esteve <asmond at orange.es> wrote
on 26/05/2010 16:03:06:<br>
<br>
> Chris wrote:<br>
> > Obviously other's experiences help and we could do with more
feedback . . . <br>
> .<br>
> A week has passed and no one answered with its case :-(. I'll try
to comment <br>
> on our own case, we have <br>
>    freenx-server   0.7.3<br>
>    nx client for Windows 3.4.0-7<br>
> <br>
> [...]<br>
> <br>
> > What I did when I was looking at this, was to try the same tasks
using both <br>
> > high quality jpeg and RGB and compare how it seemed to be on
the screen. <br>
> <br>
> In our case:  the speed difference was not a great one, the <br>
> behaviour was a bit <br>
> faster using the lossless RGB compresion.<br>
>  </font></tt>
<br>
<br><tt><font size=2>The settings are changed depending upon the link speed
you select.</font></tt>
<br>
<br><tt><font size=2>I had ADSL, yours is set to modem !!</font></tt>
<br>
<br><tt><font size=2>I was swinging windows around, which should be just
compressed</font></tt>
<br><tt><font size=2>X traffic not graphics at all.</font></tt>
<br>
<br><tt><font size=2>With RGB the deferred updates were noticable, with
a whole trail of</font></tt>
<br><tt><font size=2>window edges all round the screen, but its not a real
world test.</font></tt>
<br>
<br><tt><font size=2>I can see more sluggish text entry with RGB than jpeg,
even though</font></tt>
<br><tt><font size=2>it shouldn't make any difference.</font></tt>
<br><tt><font size=2><br>
> > I found that I couldn't distinguish between the quality of image
( on a  <br>
> > spreadsheet, which is one of our core apps, lots of thin straight
black <br>
> > lines on a white background, just what the jpeg people say they
aren't good<br>
> > at ) <br>
>  <br>
> In our case:  the presentation made a visible difference. I attach
<br>
> screenshots <br>
> of the configuration (with "modem" settings and setting
both rgb and jpeg <br>
> compression, jpeg at the highest quality) and obtaining a low quality
result <br>
> in some places of the screenshot (like the buttons),</font></tt>
<br>
<br><tt><font size=2>Yup, I see the button icons a bit blurry too, that's
lossy jpeg I guess . . . .</font></tt>
<br>
<br><tt><font size=2>> a result somewhat worse <br>
> than the Windows remote desktop protocol one, which would make us
<br>
> look like if <br>
> we had something of worse quality. This is very important. Maybe it's
a <br>
> setting that has to be tuned? :-?<br>
</font></tt>
<br><tt><font size=2>There seems to be a difference in compression methodology
between</font></tt>
<br><tt><font size=2>bitmaps and text.</font></tt>
<br>
<br>
<br><font size=2 face="Arial">From NX-XProtocolCompression.pdf</font>
<br>
<br><tt><font size=2>Quote</font></tt>
<br><font size=2 face="Arial">The current default method to encode images
in NX X sessions is JPEG, with</font>
<br><font size=2 face="Arial">quality determined according to link settings.</font>
<br>
<br><font size=2 face="Arial">Other available methods are PNG and ZLIB
X bitmap compression.</font>
<br>
<br><font size=2 face="Arial">JPEG is a lossy image format.</font>
<br>
<br><font size=2 face="Arial">Most remote display systems cannot generally
use JPEG as in these</font>
<br><font size=2 face="Arial">systems not only images but even generic
screen updates, containing</font>
<br><font size=2 face="Arial">text or other vector graphics, are encoded
as bitmaps.</font>
<br>
<br><font size=2 face="Arial">In these systems the use of JPEG would make
the resulting output clumsy.</font>
<br>
<br><font size=2 face="Arial">NX, instead, preserves the original X protocol
to handle text and graphics</font>
<br><font size=2 face="Arial">rendering and uses lossy image compression
only for X requests carrying</font>
<br><font size=2 face="Arial">actual bitmap images.</font>
<br><tt><font size=2>Unquote</font></tt>
<br>
<br><tt><font size=2>This gist of this is they they compress the X message
traffic for text,</font></tt>
<br><tt><font size=2>( mostly by cache hits and differential updates )</font></tt>
<br>
<br><tt><font size=2>which means that the choice of bitmap compression
is not going to affect</font></tt>
<br><tt><font size=2>office work so much, although we both notice that
button icons are a bit</font></tt>
<br><tt><font size=2>blurry.</font></tt>
<br>
<br>
<br><tt><font size=2>I haven't changed my view. There isn't much you can
do, but you do</font></tt>
<br><tt><font size=2> need to set the link type.</font></tt>
<br>
<br><tt><font size=2>1/ Make sure the server is up to the job</font></tt>
<br><tt><font size=2>2/ Use the fastest link you can - with ssh link encryption
you can tell</font></tt>
<br><tt><font size=2>        the users to use
an Internet Cafe instead of a 2M 3G stick</font></tt>
<br><tt><font size=2>2a/ Don't forget the server end of the link may be
loaded up</font></tt>
<br><tt><font size=2>3/ Select the correct (client) link speed whatever
it (actually) is</font></tt>
<br><tt><font size=2>4/ Minimize traffic, use rootless apps etc</font></tt>
<br><tt><font size=2>5/ Test it out for your site and applications</font></tt>
<br><tt><font size=2>6/ Don't tell the users they can tweak things.</font></tt>
<br>
<br><tt><font size=2>We await other users telling us of their experiences
!!.</font></tt>
<br>
<br><tt><font size=2>One other thing.</font></tt>
<br>
<br><tt><font size=2>Do you see any content in the client disk cache ??</font></tt>
<br>
<br><tt><font size=2>CB</font></tt>
<br>
<br><tt><font size=2>> <br>
> Thanks for you attention:<br>
> Toni<br>
> <br>
</font></tt>
--=_alternative 00314BA080257737_=--