nanogui: Thread: delayed mouse movements


[<<] [<] Page 1 of 1 [>] [>>]
Subject: delayed mouse movements
From: George Harvey ####@####.####
Date: 29 Feb 2000 23:22:51 -0000
Message-Id: <yam8094.2595.144334792@smtp.dial.pipex.com>

Hi,

I am experimenting with a port of Microwindows to an old Isicad Prisma
workstation (running uClinux). I am writing my own display driver but
using the standard serial mouse driver. While running some of the demo
programs I noticed a curious time lag effect with mouse movement, after
a large move the cursor did not seem to keep up but the next time the
mouse was moved, the cursor would leap forward and then continue.

From an examination of the code, I think that the problem lies with
the buffering of mouse movements in drivers/mou_ser.c. When the mouse
is read by GdReadMouse() it can leave data in the buffer which will
not be processed until the next time the mouse is physically moved.
I have made the following change to nanox/srvevent.c and mwin/winevent.c
which causes all buffered data to be processed whenever a mouse event
occurs. This appears to fix the problem (I suspect that the only reason
I saw it in the first place is that the Prisma is very slow at displaying
bitmaps so mouse movements could get ahead of the cursor display updates).

George Harvey
####@####.####


*** srvevent.orig.cTue Feb 29 22:14:57 2000
--- srvevent.cTue Feb 29 22:16:10 2000
***************
*** 100,114 ****
     intmousestatus;/* latest mouse status */
  
     /* Read the latest mouse status: */
!    mousestatus = GdReadMouse(&rootx, &rooty, &newbuttons);
     if(mousestatus < 0) {
        GsError(GR_ERROR_MOUSE_ERROR, 0);
        return FALSE;
-    } else if(mousestatus) {/* Deliver events as appropriate: */
-       GsHandleMouseStatus(rootx, rooty, newbuttons);
-       return TRUE;
     }
!    return FALSE;
  }
  
  /*
--- 100,113 ----
     intmousestatus;/* latest mouse status */
  
     /* Read the latest mouse status: */
!    while ((mousestatus = GdReadMouse(&rootx, &rooty, &newbuttons)) > 0) {
!       GsHandleMouseStatus(rootx, rooty, newbuttons);
!    }
     if(mousestatus < 0) {
        GsError(GR_ERROR_MOUSE_ERROR, 0);
        return FALSE;
     }
!    return TRUE;
  }
  
  /*


Subject: Re: delayed mouse movements
From: "Greg Haerr" ####@####.####
Date: 2 Mar 2000 06:11:34 -0000
Message-Id: <01e801bf840c$91f21a60$15320cd0@gregh>

: >From an examination of the code, I think that the problem lies with
: the buffering of mouse movements in drivers/mou_ser.c. When the mouse
: is read by GdReadMouse() it can leave data in the buffer which will
: not be processed until the next time the mouse is physically moved.
: I have made the following change to nanox/srvevent.c and mwin/winevent.c
: which causes all buffered data to be processed whenever a mouse event
: occurs. This appears to fix the problem (I suspect that the only reason
: I saw it in the first place is that the Prisma is very slow at displaying
: bitmaps so mouse movements could get ahead of the cursor display updates).
: 

What version of Microwindows are you running?  Microwin or Nano-X
API?  I changed an if statement to a while loop in the main GsSelect()
code that also might help with this.

Thanks for the patch.  I don't use the direct serial driver much, so I haven't
seen this, although the above fix was implemented for slower systems running
the 3d demo....

After I hear from you in regards to the version you're running, I'll probably
add this patch.

Regards,

Greg


: George Harvey
: ####@####.####
: 
: 
: *** srvevent.orig.cTue Feb 29 22:14:57 2000
: --- srvevent.cTue Feb 29 22:16:10 2000
: ***************
: *** 100,114 ****
:      intmousestatus;/* latest mouse status */
:   
:      /* Read the latest mouse status: */
: !    mousestatus = GdReadMouse(&rootx, &rooty, &newbuttons);
:      if(mousestatus < 0) {
:         GsError(GR_ERROR_MOUSE_ERROR, 0);
:         return FALSE;
: -    } else if(mousestatus) {/* Deliver events as appropriate: */
: -       GsHandleMouseStatus(rootx, rooty, newbuttons);
: -       return TRUE;
:      }
: !    return FALSE;
:   }
:   
:   /*
: --- 100,113 ----
:      intmousestatus;/* latest mouse status */
:   
:      /* Read the latest mouse status: */
: !    while ((mousestatus = GdReadMouse(&rootx, &rooty, &newbuttons)) > 0) {
: !       GsHandleMouseStatus(rootx, rooty, newbuttons);
: !    }
:      if(mousestatus < 0) {
:         GsError(GR_ERROR_MOUSE_ERROR, 0);
:         return FALSE;
:      }
: !    return TRUE;
:   }
:   
:   /*
: 
: 
: 
: ---------------------------------------------------------------------
: To unsubscribe, e-mail: ####@####.####
: For additional commands, e-mail: ####@####.####
: 
: 

Subject: Re: delayed mouse movements
From: George Harvey ####@####.####
Date: 3 Mar 2000 20:46:46 -0000
Message-Id: <yam8097.1205.139379048@smtp.dial.pipex.com>

On 02-Mar-00, Greg Haerr wrote:
>: >From an examination of the code, I think that the problem lies with
>: the buffering of mouse movements in drivers/mou_ser.c. When the mouse
>: is read by GdReadMouse() it can leave data in the buffer which will
>: not be processed until the next time the mouse is physically moved.
>: I have made the following change to nanox/srvevent.c and mwin/winevent.c
>: which causes all buffered data to be processed whenever a mouse event
>: occurs. This appears to fix the problem (I suspect that the only reason
>: I saw it in the first place is that the Prisma is very slow at displaying
>: bitmaps so mouse movements could get ahead of the cursor display updates).
>: 

>What version of Microwindows are you running?  Microwin or Nano-X
>API?  I changed an if statement to a while loop in the main GsSelect()
>code that also might help with this.

I am using the final 0.87 release.
The delayed-action effect occured with both the Microwin and Nano-X demos,
they use very similar code to read mouse events (mwin/winevent.c and
nanox/srvevent.c).

[ snip ]

Thanks,

George


Subject: Re: delayed mouse movements
From: George Harvey ####@####.####
Date: 7 Mar 2000 19:40:27 -0000
Message-Id: <yam8101.1318.142848408@smtp.dial.pipex.com>

Just to say that 0.88pre3 appears to have fixed the problem.

Thanks,

George

[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.