#🔒 Clicking with pynput lags the whole program

10 messages · Page 1 of 1 (latest)

marble yarrow
#

Hey guys, Im having trouble with click with pynput, everytime I run a function that starts clicking whole program freezes.
I was looking at docs and there it says this:

The mouse listener thread
The listener callbacks are invoked directly from an operating thread on some platforms, notably Windows.
This means that long running procedures and blocking operations should not be invoked from the callback, as this risks freezing input for all processes.
A possible workaround is to just dispatch incoming messages to a queue, and let a separate thread handle them.

Which is propably the cause of the lag, but I dont really understand what it says, can someone help me please ?

balmy oceanBOT
#

@marble yarrow

Python help channel opened

Remember to:

  • Ask your Python question, not if you can ask or if there's an expert who can help.
  • Show a code sample as text (rather than a screenshot) and the error message, if you've got one.
  • Explain what you expect to happen and what actually happens.

:warning: Do not pip install anything that isn't related to your question, especially if asked to over DMs.

Closes after a period of inactivity, or when you send !close.
marble yarrow
#

this is the function im running on button click :

def click_mouse():
    for i in range(5):
        mouse.press(Button.left)
        mouse.release(Button.left)
        sleep(1)
slate eagle
#

The docs say:
Make a new thread that will handle the long job. It will read what to do from a message queue.
Then the listener callback won't need to do the long stuff, it will only add the task to do to the queue.

Real life comparison:
Imagine a repairs company. Customers call and someone comes and do the repairs.
Right now it's only one person. When first call came, the person went to do the job (your click_mouse function). Now many others are now calling - any mouse action that would normally be captured by your listener - but there's no one who can answer the call, they're all queued waiting for someone. And there's a lot of them.

The solution is to have a separate person who takes the call and a person who does the repair.
The calls are now taken quickly - either the task gets added to the queue of repairs to do, or it gets discarded as not relevant. No wait time.
The repair person just takes the first job from the queue and does it, then takes the next task, and so on

marble yarrow
slate eagle
# marble yarrow thats making more sense, but I dont really know why would i use that queue, cant...

What if the events happen too close together?
Right now you have 5 clicks with 1 second after each.
What if you start another thread while this one is running? Then the actions will overlap. Let's say the next event happened 1.2s after the first one.
First thread clicks at time "0", then "1"... But then second thread starts at the time 1.2 and clicks. Next 1st thread clicks at time 2, then 2nd thread at 2.2... And so on until both threads did their 5 clicks.

The queue makes it so that instead of clicking at once, you'd start the second job later.
Add 3rd thread, 4th, and so on, it becomes a shitshow.

Multiple threads are fine for some uses - but when they deal with some common resource (here: mouse), the queue is better. Or even dropping the repeated events until you're free again

marble yarrow
#

!close

balmy oceanBOT
#
Python help channel closed

This help channel has been closed and it's no longer possible to send messages here. If your question wasn't answered, feel free to create a new post in #1035199133436354600. To maximize your chances of getting a response, check out this guide on asking good questions.