Menu

#104 event loop needs tickling

9.0rc4
closed
nobody
None
Bug
Core
major
2018-06-22
2017-02-13
No

This is not specific to AlphaCocoa, it happens also in AlphaX:

Sometimes it appears that the event loop waits for something and needs tickling before continuing.
For example, it happens often that when invoking Compare Windows nothing happens -- until you move the mouse (no click or other action needed), then the diff starts. It is not always it happens but sometimes.

Another example, perhaps different, is when backwards synching from Skim. Nothing happens, until you manually shift to Alpha, then the action starts, with Alpha correctly selecting the line. Again, it is not systematical, perhaps one out of ten times.

Discussion

  • Francois Chaplais

    Is this strictly for mouse events (no keyboard shortcut)?

     
  • Joachim Kock

    Joachim Kock - 2017-02-14

    there may be casual circumstances giving the feeling that Alpha is not
    reacting. The most obvious which comes to mind is when one
    (accidentally) hits a combo which is bound to prefixBinding.

    The issue is not about prefix bindings (which by the way cannot be tickled by cursor movements).

    Is this strictly for mouse events (no keyboard shortcut)?

    A key press is also enough to wake the event loop.

     
  • Bernard Desgraupes

    This is possibly another manifestation of the menu selection issue described in Ticket #10 and Ticket #97. These tickets are fixed now, so hopefully this one is too. Let's wait for the forthcoming 9.0b1 release...

     
  • Bernard Desgraupes

    Not sure where to look. Do you have something reporducible ?

     
  • Bernard Desgraupes

    After close examination, I think I now understand what's going on there. It appears that the delay sometime observed in the diff command is caused by the xserv::invoke proc. More specifically the bottleneck is in the [launch] command which is in fact [tclAE::launch]: this command, defined in the tclAE extension, uses the Carbon Events model and, when the target application is not already running, it has to launch it and install a Carbon Event Handler waiting for an AppDidLaunch notification in order to retrieve the PSN (Process Serial Number). The command then calls ReceiveNextEvent() and waits: this is where the delay occurs (and it depends on the Carbon Events Manager).
    I have fixed this by modifying the proc [::xserv::executeApp] in xserv.tcl: it calls [switchTo] to launch the application (this is fast), then calls [tclAE::launch] to retrieve the PSN. Since the app is already running, this avoids the overhead of messing with Carbon Events because, in that case, [tclAE::launch] obtains the psn directly.
    Changes committed to the repository (rev. 1481 (sourceforge.net)).

     
  • Bernard Desgraupes

    • status: open --> fixed
    • Version: 9.0a14 --> 9.0rc4
     
  • Bernard Desgraupes

    • status: fixed --> closed
     

Log in to post a comment.

MongoDB Logo MongoDB