link@ucunix.san.uc.edu (Virginia Link) (05/09/91)
Every since I have had my 3000, I have noticed that any "sun mouse " programs seem to be very jumpy. By this I mean, When you use a mouse program that does auto-activation on windows, the mouse pointer will pause for a substantial amount of time on the window boundry while the ActivateWindow is being performed. Then after the activation, The pointer will jump to its new location. This new location is usually not in the immediate vicinity of wher it stopped, thereby making it look as if the pointer jumped. This can be very annoying when aiming for a certain button, and end up over shooting it because of this problem. I have noticed that the problem is diminished if the workbench is set for backdrop and not window. I have also noticed that when I run a program that opens up its own screen and pops upa window, transition from auto-activation are very smooth on that screen. This problem does not seem to exist on 1.3 at all. My question is, Is there anything else going on in 2.0 that needs to be taken care of to get the sun mouse application to be "smooth" ? vlink
jil@cs.iastate.edu (James Lathrop) (05/09/91)
link@ucunix.san.uc.edu (Virginia Link) writes: >Every since I have had my 3000, I have noticed that any "sun mouse " >programs seem to be very jumpy. By this I mean, When you use a mouse program >that does auto-activation on windows, the mouse pointer will pause for >a substantial amount of time on the window boundry while the ActivateWindow >is being performed. Then after the activation, The pointer will jump to its >new location. This new location is usually not in the immediate >vicinity of wher it stopped, thereby making it look as if the pointer jumped. >This can be very annoying when aiming for a certain button, and end up >over shooting it because of this problem. I have noticed that the problem is >diminished if the workbench is set for backdrop and not window. I have also noticed >that when I run a program that opens up its own screen and pops upa window, >transition from auto-activation are very smooth on that screen. >This problem does not seem to exist on 1.3 at all. >My question is, Is there anything else going on in 2.0 that needs to be taken >care of to get the sun mouse application to be "smooth" ? >vlink I had the same problem. I then tried MachIII version 3.0 and it was much better. (About the same as 1.3) Version 3.0 of MachIII has some problems and you have to be creative to get it to work. Version 3.1 on Fish disk 371 fixes these bugs I hear. I can't test this since my 1950 has been at C= for the past four months getting the vertical jitters removed or something and my borrowed monitor just went away. I may start complaining about that one soon. James Lathrop jil@judy.cs.iastate.edu
peter@cbmvax.commodore.com (Peter Cherna) (05/09/91)
In article <1991May8.234800.24930@ucunix.san.uc.edu> link@ucunix.san.uc.edu (Virginia Link) writes: >My question is, Is there anything else going on in 2.0 that needs to be taken >care of to get the sun mouse application to be "smooth" ? The window borders of the New Look of 2.0 does take a bit longer to render than the much simpler (and uglier) borders of 1.3. We've modified AutoPoint (the Sun-mouse style commodity we ship) to wait until the mouse has stopped (or slowed down a lot) before activating the window it's over. This has several benefits: - Mouse travel isn't jerky. - You can travel to the menus without methodically hitting the menu button before you begin your motion. - Windows that are along the way to your destination aren't needlessly activated. - It's a better emulation of a Sun-mouse, since Sun mice also have this lag. >vlink Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "If all you have is a hammer, everything looks like a nail."
blgardne@javelin.sim.es.com (Blaine Gardner) (05/09/91)
link@ucunix.san.uc.edu (Virginia Link) writes: >Every since I have had my 3000, I have noticed that any "sun mouse " >programs seem to be very jumpy. Both Dmouse and ClockDJ seem to work without any noticable jumpiness on my A3000. That is as long as I'm running a 4 color WB screen, with an 8 color WB, there is a noticable lag. Are you running an 8 or 16 color WB? [I've aimed followups to comp.sys.amiga.misc] -- Blaine Gardner @ Evans & Sutherland 580 Arapeen Drive, SLC, Utah 84108 blgardne@javelin.sim.es.com BIX: blaine_g DoD #46 My other motorcycle is a Quadracer. FJ1200 Now I know why they are called BUTTERflys!
link@ucunix.san.uc.edu (Virginia Link) (05/10/91)
In article <jil.673754087@judy.cs.iastate.edu> jil@cs.iastate.edu (James Lathrop) writes: >link@ucunix.san.uc.edu (Virginia Link) writes: > > > >>Every since I have had my 3000, I have noticed that any "sun mouse " >>programs seem to be very jumpy. By this I mean, When you use a mouse program >>that does auto-activation on windows, the mouse pointer will pause for >>a substantial amount of time on the window boundry while the ActivateWindow >>is being performed. Then after the activation, The pointer will jump to its >>new location. This new location is usually not in the immediate >>vicinity of wher it stopped, thereby making it look as if the pointer jumped. >>This can be very annoying when aiming for a certain button, and end up >>over shooting it because of this problem. I have noticed that the problem is >>diminished if the workbench is set for backdrop and not window. I have also noticed >>that when I run a program that opens up its own screen and pops upa window, >>transition from auto-activation are very smooth on that screen. >>This problem does not seem to exist on 1.3 at all. > >>My question is, Is there anything else going on in 2.0 that needs to be taken >>care of to get the sun mouse application to be "smooth" ? > >>vlink > > > >I had the same problem. I then tried MachIII version 3.0 and it was >much better. (About the same as 1.3) Version 3.0 of MachIII has some >problems and you have to be creative to get it to work. Version 3.1 >on Fish disk 371 fixes these bugs I hear. I can't test this since >my 1950 has been at C= for the past four months getting the vertical >jitters removed or something and my borrowed monitor just went away. >I may start complaining about that one soon. > >James Lathrop >jil@judy.cs.iastate.edu I have tried MachIII, and it has the problems as do all the rest. Obviuosly they have made some big changes to the workbench screen and it's windows that is causing some problems that is not present on other screens. But I don't have any idea what those are. Does anyone out there know what's going on in 2.0 ?
link@ucunix.san.uc.edu (Virginia Link) (05/10/91)
In article <21419@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >In article <1991May8.234800.24930@ucunix.san.uc.edu> link@ucunix.san.uc.edu (Virginia Link) writes: >>My question is, Is there anything else going on in 2.0 that needs to be taken >>care of to get the sun mouse application to be "smooth" ? > >The window borders of the New Look of 2.0 does take a bit longer to render >than the much simpler (and uglier) borders of 1.3. We've modified >AutoPoint (the Sun-mouse style commodity we ship) to wait until the >mouse has stopped (or slowed down a lot) before activating the window >it's over. This has several benefits: >- Mouse travel isn't jerky. >- You can travel to the menus without methodically hitting the menu > button before you begin your motion. >- Windows that are along the way to your destination aren't needlessly > activated. >- It's a better emulation of a Sun-mouse, since Sun mice also have > this lag. > >>vlink > > Peter >-- >Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. >{uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com >My opinions do not necessarily represent the opinions of my employer. >"If all you have is a hammer, everything looks like a nail." After reading a few replies to my pleas, I have tried several things. One - It does make a big difference when reducing the number of colors being displayed by workbench. The activation response is much better with only four colors. Two - If workbench is set to a backdrop, window activation is even better. Three - Other programs, such as Ncomm with hi-res and 8 colors have much smoother operation when doing activations. Questions- Is there any way to reduce the lag the pointer experiences when the workbench has 8 or 16 colors other than delaying the activation as you mentioned? Why is the pointer operation much smoother when running on another screen like Ncomm when there is also a hires display and 8 colors or even 16? And it seems like the 68030 should make up for any extra overhead required for the 2.0 windows. vlink
peter@cbmvax.commodore.com (Peter Cherna) (05/10/91)
In article <1991May10.003358.2007@ucunix.san.uc.edu> link@ucunix.san.uc.edu (Virginia Link) writes: >In article <21419@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >After reading a few replies to my pleas, I have tried several things. >One - It does make a big difference when reducing the number of colors being > displayed by workbench. The activation response is much better > with only four colors. Right, there is less rendering work to do. >Two - If workbench is set to a backdrop, window activation is even better. One less window is affected. >Three - Other programs, such as Ncomm with hi-res and 8 colors have > much smoother operation when doing activations. When a window is activated or unactivated, all the gadgets that are in its border need to be redrawn. Workbench has several extra (two silders and four arrows). >Questions- Is there any way to reduce the lag the pointer experiences > when the workbench has 8 or 16 colors other than delaying the > activation as you mentioned? That's the best way. Note that the latest MachIII that just appeared on a Fish disk (471) has the delayed-activation trick. > And it seems like the 68030 should make up for any extra overhead > required for the 2.0 windows. It helps, but some of the operation is still blitter-based. >vlink Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "If all you have is a hammer, everything looks like a nail."