Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!think.com!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.windows.x
Subject: Re: Dialup X
Message-ID: <19910201153405.6.BARMAR@OCCAM.THINK.COM>
Date: 1 Feb 91 15:34:00 GMT
References: <9102010006.AA11925@pepper.com>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 28


    Date: Thu, 31 Jan 91 16:06:27 PST
    From: lupine!dc@uunet.UU.NET (Dave Cornelius)

    >From a UI point of view, having the server 'closely coupled' to 
    the mouse allows the cursor to change shape at window boundaries,
    and allows the window manager to change highlighting apropos these
    boundary crossings.  A round-trip through the serial line
    to effect these changes can be a bit troublesome.

Perhaps another useful approach would be something between GraphOn's and
Xremote, where the protocol sent down the serial line were higher level
than frame buffer operations, but not the full X protocol.  For example,
aspects of the protocol related to client management could be done on
the host, rather than including client information in the serial line
protocol.

    I'm note quite sure what you mean by 'optimize use of the serial
    line better'.  

I was talking about output to non-visible portions of windows.  GraphOn
presumably does this clipping on the host, and doesn't waste serial
bandwidth sending bits that won't be displayed.  On the other hand, this
means that the terminal can't cache it locally so that raising the
window is fast.  However, the host could wait until the serial line is
idle and then forward the bits.

                                                barmar