Polling the mouse

[Scott Raney]

On Thu, 21 Feb 2002 Curry <curry at kagi.com> wrote:
> 
> Scott Raney wrote:
> 
> > Yes.  The full list of functions to avoid because they are deprecated is:
> > the mouse
> > the mouseClick
> > the mouseH
> > the mouseV
> > the mouseLoc
> > the optionKey
> > the commandKey
> > the controlKey
> > 
> > And the very worst thing to do with any of these is "repeat until
> > <function>", which will condemn you to the fires of eternal damnation
> > in multiuser hell ;-)

I noticed you CCed the MetaCard list, which is a good thing, I guess,
though they're getting dumped into the middle of the discussion.
Here's the key part of my previous message, just to bring them up to
speed:

  The long answer, and probably much more than you want to know, is
  that "the mouseClick" is really the problem here, not "the mouse".
  "the mouse" could in theory be done asynchronously.  If this were
  changed you'd still have the performance issue to deal with (i.e.,
  "repeat until" would never be as smooth as using mouseMove messages
  and would eventually cause the OS to start penalizing your app), but
  reliability wouldn't because this information can be queried
  directly from the OS on all platforms.  You'd also be subject to the
  normal behavior of async functions (e.g., in HC, "the mouse" returns
  "down" if the user clicked down anytime between when the handler
  started running and when the function is called, whereas an async
  implementation would only return "down" if it was actually down when
  you made the call).

  The problem with "the mouseClick" is that of state management and
  event order: it has to wait for the mouse to go down and then back
  up.  Worse, at least for HC compatibility, is that if you do
  something in a script that takes a few seconds and click twice in
  that interval, "the mouseClick" will return true *twice*.  This
  means that it's necessary to maintain a queue of these mouse events
  and check the whole queue each time the function is called to see if
  there is both a mouseDown and a mouseUp message in it, and pull them
  out as a pair if so.  And of course you can't just leave the rest of
  the events in the queue either, because some of them (like socket
  events and redraws) need to be handled independently of what the
  currently running handler is doing.  Doing this cross-platform is
  horrendously complicated, and results in compromized reliability for
  *everything*, not just the mouseClick function.  Which is why we
  want to (and plan to) remove this functionality, or at least
  substantially modify it to remove this queueing aspect (e.g., the
  mouseClick would return true only if you clicked down and up any
  time between the start of the handler and when you made the call,
  and once it returned true *all* state information would be tossed
  out so it wouldn't return true again until the user clicked again
  after the function returned true, even if they clicked multiple
  times before the first call).

It'd also be good to discuss the topic of sync/async polling on the HC
and SC mailing lists to get a sense of how aware people are of this
issue (I just responded to one poster on the use-revolution list who
wasn't aware of this behavior of the mouse function, though lord knows
we got enough bug reports about this back when MetaCard did a simple
async report).

> Scott, I understand the problems of the OS penalty due to hogging the
> computer with polling of mouse functions during a repeat, but there are
> different kinds of software; in some cases, we may want to make software
> that is supposed to be the only main application running on a computer, for
> example, a game, a presentation, or an educational application with a lot of
> animation.
> 
> Often, the documentation may even advise users of these types of programs to
> not run other applications unnecessarily at the same time for better
> performance. With these types of applications, often you would be
> ill-advised to run other major software at the same time anyway, not just
> because of its effect on the other software, but also because of other
> software's effect on it.

Understood, and that's why we added the keysDown function, which is a
much better way to do this kind of thing than using keyDown messages
and the optionKey/commandKey/shiftKey functions.  I guess all that
remains is a async mouse polling function, but we never considered
this necessary because using message is always possible (and always
preferred) in this case.

> For example, in one game project, I started off with the mouseMove message,
> and then had to switch to send..in plus the mouseLoc (once per handler),
> because mouseMove was not nearly responsive enough. (The object was always
> moving toward the mouse, but at its own speed, not directly tied to the
> mouse.) This was much more responsive.

I can't see why this would be the case unless you're running on a very
slow system, moving very large objects or a large number of objects,
or maybe doing a lot of other stuff in the background (like running
movies or animated GIFs).  Polling with send .. in and the mouseLoc is
one way around the problem, but in general this approach (let alone
using "repeat until ...") will result in a *less* responsive
application because a lot of extra work is being done compared with
the optimal solution of just using the mouseMove messages.

> There are comparable situations with the other functions. I have no problem
> with the mouseClick going out. It's an obvious case. But I think it would be
> terrible to remove the others functions which were mentioned. As Scott said,
> it's using them with repeats that causes the problems.

And the fact that they're synchronous now, though this is actually
"fixed" for the optionKey/commandKey/shiftKey functions in 2.4.2, was
fixed for the mouseLoc awhile back, and could easily be fixed for the
mouse function.  It is just the mouseClick that is hard to solve any
other way.

> So, first, can we be assured that these functions will still remain, at
> least asynchronously, in the future? Otherwise, if the corresponding
> messages don't work well enough for a certain task, we will be in a jam
> someday.
> 
> Secondly, using these functions synchronously allows much more convenient
> scripting for testing, personal projects, students (as someone mentioned),
> etc. Why not keep the functions synchronous, with the exception of
> mouseClick which could be turned asynchronous or simply trashed, and leave
> the responsibility of using them correctly up to the scripter?

Sounds reasonable to me, but given the number of bug reports we've
received on this issue, you and I may be in the minority.
  Regards,
    Scott

> Curry Kenworthy

********************************************************
Scott Raney  raney at metacard.com  http://www.metacard.com
MetaCard: You know, there's an easier way to do that...


_______________________________________________
metacard mailing list
metacard at lists.runrev.com
http://lists.runrev.com/mailman/listinfo/metacard