[<<] [<] 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 [>] [>>] |