Hello,
>>>>> "MO" == Michael Ossmann <[EMAIL PROTECTED]> writes:
>> could someone please tell me where I can read some information on
>> the Java Options for VNC and in particular on these:
>>
>> <param name="CopyRect" value="Fast"> <param name="Raw pixel
>> drawing" value="Reliable">
MO> I don't think there is any documentation for these.
You're right, there's no documentation. However, I plan to prepare a
short description of every option and include this information into
the TightVNC distribution.
MO> You'll have to look through the source. From a quick look, it
MO> appears to me that you should always set both these to Fast. The
MO> Reliable Raw pixel drawing method appears incredibly inefficient:
MO> for (int j = y; j < (y + h); j++) {
MO> for (int k = x; k < (x + w); k++) {
MO> int pixel = rfb.is.read(); sg.setColor(colors[pixel]);
MO> sg.fillRect(k, j, 1, 1); pig.setColor(colors[pixel]);
MO> pig.fillRect(k, j, 1, 1);
MO> }
MO> }
MO> My guess is that the only reason it was ever there was for some
MO> debugging purpose.
Well, that's not that simple. Long time ago, I asked a question in
this mailing list: Does anybody have problems with "Raw pixel drawing"
option set to "Fast"? I have not received any reply and therefore I've
decided that having only "Fast" would satisfy everybody. But recently
I was informed that the "Fast" setting (that is, using drawImage()
method instead of setColor()/fillRect() for each pixel) does not work
with Apple's JVMs (even if they're claimed to be 1.1-"compatible")
under MacOS 9. So, certain reasons to set "Raw pixel drawing" to
"Reliable" do exist.
By the way, certain JVMs operate surprisingly fast in the "Reliable"
mode, notably Microsoft's JVMs (but yes, most other JVMs work slowly).
MO> These options don't exist in the TightVNC Java client which looks
MO> like it implements the equivalent of "Fast" for both options.
Well, TightVNC Java viewer is somewhat different in this aspect.
Recent TightVNC viewers never use and cannot use fillRect() due to the
way I implemented local cursor support. So the "Raw pixel drawing" and
"CopyRect" options are not applicable to current TightVNC viewer
version.
>From the other side, the things are changing. Currently, I
re-implemented "local cursor" preparing for for the upcoming TightVNC
version, and now I can use fillRect() again. I even thought about
re-including "Raw pixel drawing" option to solve problems with Mac
JVMs, but now it's seems like I don't have to: drawImage() seems to
work under MacOS 9 in the 24-bit color format (which was implemented
recently ;-).
>> I am trying to find a was to speed up the screen updates on the
>> client machines and also the colors seem to be off even though I am
>> running only 16 bit resolution from my Linux box.
Previous versions of the Java viewer (both standard VNC and TightVNC)
were able to handle only 8-bit colors (BGR233 color format). This
means that colors could look somewhat incorrect in Java viewers. Next
TightVNC Java viewer will support full 24-bit colors, JPEG compression
in the Tight encoding, and a number of other great improvements. ;-)
--
With Best Wishes,
Constantin
---------------------------------------------------------------------
To unsubscribe, mail [EMAIL PROTECTED] with the line:
'unsubscribe vnc-list' in the message BODY
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
