Board index » delphi » Need to improve a remote control software...

Need to improve a remote control software...


2005-09-08 02:53:45 AM
delphi123
Hi!
We have developed a remote control application, and it works "fine", so we
can see the remote desktop on our screen, move the cursor, click, write,
etc...
The "problem" is that, we need it to go FASTER!
I know it depends on which components we use, network speed and the source
code used, but...
Which are the best methods to transfer images and info between computers?
UDP or TCP? (we use Indy idTCP components)
To transfer the desktop image...
we capture the screen to a BMP, then save it to JPG, compress it using UCL
compression and save to a Stream, just to send it to the remote computer.
Is this the faster method?
Any ideas to improve the speed of this type of applications?
 
 

Re:Need to improve a remote control software...

Hello,
Quote
To transfer the desktop image...
we capture the screen to a BMP, then save it to JPG, compress it using UCL
compression and save to a Stream, just to send it to the remote computer.
Just an idea:
Since JPG is an image compression format you do a "double compression".
Skip JPG and compress your BMP with UCL comression directly...
Sven
 

Re:Need to improve a remote control software...

"Santy Concepción" <XXXX@XXXXX.COM>writes
Quote
To transfer the desktop image...
we capture the screen to a BMP, then save it to JPG, compress it
using UCL compression and save to a Stream, just to send it to
the remote computer. Is this the faster method?
JPG is already compressed quite a bit, so using additional compression won't
help much. I'd suggest using either JPG or UCL but not both. Also,
since JPG is a lossy format anyway, it would probably be better to just
compress the BMP directly instead of using JPG (unless you don't care about
reproducing the original quality of the images on the receiving end).
Also, the best way to send a series of images quickly is to not send
complete images to begin with. After you have sent the first image, each
subsequent image should only send the *differences* from the previous image
for the portions that have actually changed. This means that you are
transmitting much less data, and performing less intense image updates on
the receiving end. Of course, you should send a complete image
periodically, say once a minute or so, to ensure that the display on the
receiving end stays in sync and can recover if the image differentials beome
out-of-sync or corrupted.
Gambit
 

Re:Need to improve a remote control software...

Remy Lebeau (TeamB) writes:
Quote
"Santy Concepción" <XXXX@XXXXX.COM>writes
news:431f36fa$XXXX@XXXXX.COM...


>To transfer the desktop image...
>we capture the screen to a BMP, then save it to JPG, compress it
>using UCL compression and save to a Stream, just to send it to
>the remote computer. Is this the faster method?


JPG is already compressed quite a bit, so using additional compression won't
help much. I'd suggest using either JPG or UCL but not both. Also,
since JPG is a lossy format anyway, it would probably be better to just
compress the BMP directly instead of using JPG (unless you don't care about
reproducing the original quality of the images on the receiving end).

Also, the best way to send a series of images quickly is to not send
complete images to begin with. After you have sent the first image, each
subsequent image should only send the *differences* from the previous image
for the portions that have actually changed. This means that you are
transmitting much less data, and performing less intense image updates on
the receiving end. Of course, you should send a complete image
periodically, say once a minute or so, to ensure that the display on the
receiving end stays in sync and can recover if the image differentials beome
out-of-sync or corrupted.


Gambit


Good comments. JPG can take a bit of time to generate. So I would
suggest staying away from JPG. and are not that good for text - mainly
for pictures. I have done JPG on black and white and text and found
that Tif was smaller.
Jim P.
 

Re:Need to improve a remote control software...

Santy Concepcisn writes:
Quote
Hi!

We have developed a remote control application, and it works "fine",
so we can see the remote desktop on our screen, move the cursor,
click, write, etc...

The "problem" is that, we need it to go FASTER!

I know it depends on which components we use, network speed and the
source code used, but...
Which are the best methods to transfer images and info between
computers? UDP or TCP? (we use Indy idTCP components)
You need to send differences (see below) so UDP is out. UDP would mean
your code would have to deal with missing parts of an image or diff,
making your code more complex and slower.
Quote
To transfer the desktop image...
we capture the screen to a BMP, then save it to JPG, compress it
using UCL compression and save to a Stream, just to send it to the
remote computer. Is this the faster method?
Forget about image formats. Send the screen size and colour-bit depth
once, then send one full screen capture (don't waste your time
converting it to a BMP). Grab another screen capture, and by comparing
with the previous capture, transmit the differences only. Use lossless
compression (Indy has compression code, but there are also
public-domain / open-source compression routines freely available).
You cannot use JPG with this methodology: even a slight image change
will give significantly different images because of the way JPG
compression works, and the number of different bytes would frequently
be much higher (on a simplified basis, JPG smudges adjacent colours -
changing one pixel from red to blue affects the adjacent pixels also).
JPG is also just ugly, particularly in this case: the lines at window
borders and at the mouse cursor will not be sharp, and will eventually
give the user a pain in the head. JPG is OK for photos but very poor
with lines.
Ciaran