[FreeNX-kNX] NX screen refresh performance

Wed May 19 15:31:07 UTC 2010

Toni Asensi Esteve <asmond at orange.es> wrote on 19/05/2010 14:31:06:

Hi Toni

> Chris wrote:
> 
> Before adding the new information to the FAQ I would like that we 
discuss one 
> thing:

OK 

> > RGB is lossless encoding, ie mostly don't compress 
> 
> > Personally, I find it slower than a steamroller, unless on a LAN link. 

> > jpeg is everywhere for a reason !! 
> Mmm... I beg to differ, jpeg is not everywhere :-(. You'll see a lot of 
.png 
> files.

Yes. Thank you, Toni . I didn't mean exculsively everywhere.

> Apart of being a lossless compression, the reason of using a RGB 
> compression is that if you are going to save an image that has not 
> photographs 
> nor gradients, for example a screenshot of a simple window of a 
program... if 

yup . . .

> you use a jpeg compresion you'll have a big file and inside the 
> resulting image 
> you'll have "blurry text" and "blurry lines". This is because jpeg 
compresion 
> was designed for photographs and similars, not for images that have 
> only text, 

yup

> lines, squares and so. For those cases, a png compresion produces 
smaller 
> files.
> 

right . . .

> The JPEG FAQ explains it in http://www.faqs.org/faqs/jpeg-faq/part1 
(search 
> inside the text "When should I use JPEG, and when should I stick with 
GIF", 
> knowing that the PNG format can represent all the necessary colors, 
> unlike the 
> GIF one).

Right . . . for hard lines and areas of the same colour.
gif compresses to smaller
png is mostly better than gif for the above
jpeg for the above is larger and may won't be lossless even if the image
   is just an area of all the same colour.

But  . . .

I didn't bother with that, I just compared response times over NX
sessions, which takes everything into account.

All of the other forms of compression involved -  X session traffic
compression, the disk/memory cache sizes, the cache access time,
cpu, number of users, link speeds etc

ie. all the things nomachine included, (except the localized X round
trip reduction, which applies to all sessions equally).

I'm not sure what NX uses when you select RGB compression,
because they don't say, though as it differs from X bitmaps there
must be some compression, so I guess it's just zipped in one form
or another, which would be lossless.

It may involve gif or png . . .

or 

it may just be a compressed bitmap.

This would fit in with what nomachine say in their instructions :-

QUOTE ( from client-guide )

Only use RGB compression
------------------------------
Use only the lossless encoding. 
This compression is advisable on fast links, since the high image
 quality increases the data to be sent.

UNQUOTE

Which I take to mean : -

"advisable ONLY on fast links, since . . . increases the data . . .sent"

So

Viewing the NX session overall, rather than just compression algorithms . 
.

The other algorithms used in an NX session, may in fact prove more
significant than straight compression, for example differential
updates of screens and cache hits particularly . . .

Lots of small chunks of screen won't compress much.

Hitting them in the cache however, will be much quicker than any
compression over a slow link, particularly with differential
screen updates.

In my view, each site needs to choose the setting which are best for that
site's OVERALL performance, which when other things are taken into account
cache, partial updates etc, may well not be the smallest form of 
compression
at all.

What I did when I was looking at this, was to try the same tasks using 
both
high quality jpeg and RGB and compare how it seemed to be on the screen.

I found that I couldn't distinguish between the quality of image ( on a 
spreadsheet, which is one of our core apps,
lots of thin straight black lines
on a white background,
just what the jpeg people say they aren't good at )

but

that the RGB response time was noticably slower, even for typing.

I've just tried it again now, seeing that you've mentioned it.

When I try swinging a window around in RGB only, it goes round a
couple of times than stops with a jerk for a few second.

I type a line of high speed gobbledegook (as you can see I'm good
at that) and even that doesn't keep up with me.

It reminded me of driving behind a slow moving vehicle.

Under jpeg compression, even at high quality, the window just
keeps on moving around under the mouse pointer.

OK it's not real world (for a user doing some work anyway), but
it certainly generates some traffic and hits the end stops.

I'm running this over two adsl links from the same provider, one
6M the other 12M , so it's deferring updating the screens a little 
but it fits in with what nomachine say as quoted above about RGB
and fast links.

All this prompted me to leave the default settings at just jpeg,
not even going to both.

The setting :-

QUOTE

Use both JPEG and RGB compression
------------------------------------------
The adaptive compression dynamically selects a lossy or a lossless 
encoding depending on how compressible the image data is. 

UNQUOTE

Adaptive compression, as they call it may give smaller compression,
but I think you have to compress both ways to prove which is the best.

Its the overall performance which counts and that's the only way
to approach it.

All the algorithms are tied together to work best overall 
ie the compression must work with differential screen updates
and caching, not just on its own.

It's a case of try each in turn and choose the best for your
circumstances.

Obviously other's experiences help and we could do with
more feedback . . . . .

> 
> Greetings:
> Toni
> ________________________________________________________________
>      Were you helped on this list with your FreeNX problem?
>     Then please write up the solution in the FreeNX Wiki/FAQ:
> 
> 
http://openfacts2.berlios.de/wikien/index.php/BerliosProject:FreeNX_-_FAQ
> 
>          Don't forget to check the NX Knowledge Base:
>                  http://www.nomachine.com/kb/ 
> 
> ________________________________________________________________
>        FreeNX-kNX mailing list --- FreeNX-kNX at kde.org
>       https://mail.kde.org/mailman/listinfo/freenx-knx
> ________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/freenx-knx/attachments/20100519/b440ed24/attachment.html>