Thoughts and suggestions
Greg Breland
gbreland "at" healthtech.net
Tue, 12 Sep 2000 19:33:24 +0000
You are correct, I forgot about non incremental updates. I looked around
the source and here are the problems:
There is a function called HandleBasicDesktopEvent() which is an event
handler for the desktop widget that handles when new parts of the viewer are
exposed and need to be painted and unsets any keydowns when the window
looses focus. In fullscreen mode, this handler gets initialized before the
window is sized and placed. The comments in the code say this is necessary.
All the problems are caused by the function call
ToplevelInitAfterRealization(); in vncviewer.c.
The HandleBasicDesktopEvent() does not need to be initialized until after
ToplevelInitAfterRealization();. I do not know enough about Unix programming
to know how to do this as just declaring the handler after realization of
the widgets causes a segfault. Maybe a RawHandler? The event type is
always 12, so handling it in the HandleBasicDesktopEvent() by event type
will not work. A global var could also solve the problem, but this code is
pretty elegant to mess up like that.
Below is a detailed description of what code in
ToplevelInitAfterRealization(); causes problems.
Here is the startup rects from my debug output:
(1) Encoding: 5 x:0 y:0 w:1024 h:768 Size: 110193 Total Rects:1
(2) Encoding: 5 x:0 y:0 w:1024 h:768 Size: 110193 Total Rects:2
(3) Encoding: 5 x:0 y:0 w:986 h:702 Size: 75091 Total Rects:3
(4) Encoding: 5 x:986 y:0 w:38 h:702 Size: 1120 Total Rects:4
(5) Encoding: 5 x:0 y:702 w:1024 h:66 Size: 33717 Total Rects:5
(1) is good, this is caused by the realization of the top level window and
is what gives you your initial display.
(2) is caused by reparenting the window to root in fullscreen.c,
FullScreenOn(). This helps disable the Window Manager from managing the
window. Commenting out this line did not affect my usage of the viewer, but
I am sure it is here for a good reason.
(3) is caused by XtUnmanageChild(viewport); in FullScreenOn();. This is
done so that the viewport can be positioned in the center of the Window.
(4) This one seems to be related to (2), but I can not explain why only that
it goes away if (2) goes away.
(5) Same as (4)
Greg Breland
> -----Original Message-----
> From: Const Kaplinsky [mailto:const "at" ce.cctpu.edu.ru]
> Sent: Monday, September 11, 2000 12:02 PM
> To: vnc-list "at" uk.research.att.com
> Subject: Re: Thoughts and suggestions
>
>
> >>>>> "GB" == Greg Breland <gbreland "at" healthtech.net> writes:
>
> GB> I had just gotten through hacking the Linux vncviewer source to
> GB> add logging of rects received from the server. You are right, the
> GB> initial startup of the viewer in fullscreen mode is very different
> GB> from the normal mode.
>
> GB> What I did to the source was add logging to the hextile.c file
> GB> every place that the ReadFromRFBServer() command was used. I also
> GB> collected some stats along the way, here are the stats using
> GB> hextile encoding for connecting to a 1024x768 Xvnc server with the
> GB> modified viewer:
>
> GB> ------------------------------ Encoding: 5 x:0 y:0 w:1024 h:768
> GB> Size: 110193 Total Rects:1 Encoding: 5 x:0 y:0 w:1024 h:768 Size:
> GB> 110193 Total Rects:2 Encoding: 5 x:0 y:0 w:986 h:702 Size: 75091
> GB> Total Rects:3 Encoding: 5 x:986 y:0 w:38 h:702 Size: 1120 Total
> GB> Rects:4 Encoding: 5 x:0 y:702 w:1024 h:66 Size: 33717 Total
> GB> Rects:5
>
>
> GB> Total First Update: 323 KB ------------------------------
>
> GB> The encoding type of 5 is hextile, the size is in bytes and the
> GB> total rects are the number of top level rects, not sub-rects of
> GB> hextile. Compare this to the normal output of non-fullscreen:
>
> GB> ------------------------------ Encoding: 5 x:0 y:0 w:1024 h:768
> GB> Size: 110179 Total Rects:1
>
> GB> Total First Update: 107 KB ------------------------------
>
> GB> So the full screen mode sends exactly 3 times the information
> GB> needed to start the session. After this initial noise, everything
> GB> seems to operate as normal.
>
> GB> Notice the size difference between the two full screen updates.
> GB> This is odd and I can not explain it. Even when I repeatedly
> GB> restarted a normal session, the size would vary a little. The
> GB> screen is the same each time as I was very careful not to send it
> GB> even one mouse or key event.
>
> GB> I think the problem is in the server, since the client merely
> GB> issues a request for any new updates. I have not even started
> GB> looking at the server code on the Linux side. Anyone know why the
> GB> Xvnc server would do this in fullscreen mode?
>
> No, the problem is in the vncviewer. It can ask the server for two
> types of framebuffer updates: full and incremental ones. Normally, a
> client should pass the only request for the full framebuffer when it
> has been invoked and then it should ask only for incremental updates.
> But in fullscreen mode it actually sends three requests for the whole
> framebuffer contents. Here is some debugging output for a typical
> vncviewer session:
>
> request: rectangle at 0,0; size 1024*768; full framebuffer
> request: rectangle at 0,0; size 1024*768; incremental update
> request: rectangle at 0,0; size 1024*768; full framebuffer
> request: rectangle at 0,0; size 1024*768; incremental update
> request: rectangle at 0,0; size 1024*768; incremental update
> request: rectangle at 0,0; size 1024*768; full framebuffer
> request: rectangle at 0,0; size 1024*768; incremental update
> request: rectangle at 0,0; size 1024*768; incremental update
> [all of the following update requests are incremental]
>
> But I have not tried to find the problem in the source yet.
>
> --
> With Best Wishes,
> Constantin
> ---------------------------------------------------------------------
> To unsubscribe, send a message with the line: unsubscribe vnc-list
> to majordomo "at" uk.research.att.com
> See also: http://www.uk.research.att.com/vnc/intouch.html
> ---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at" uk.research.att.com
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------