microsoft / PowerToys

Windows system utilities to maximize productivity

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Perf] Reduce the amount of time the EVENT_OBJECT_LOCATIONCHANGE hook is enabled

TheMrJukes opened this issue · comments

Summary of the new feature/enhancement

Simply moving the cursor is enough to generate an EVENT_OBJECT_LOCATIONCHANGE.
Last I checked, PT registers for EVENT_MIN/EVENT_MAX in SetWinEventHook.
You'll notice that moving the cursor around the screen quickly is enough to spike PT CPU usage to 3-5% depending on the PC.
The idea is to reduce the amount of time PT is spent registered to receive EVENT_OBJECT_LOCATIONCHANGE and other events it does not need to process.

Proposed technical implementation details (optional)

TheMrJukes/PowerToys@master...TheMrJukes:user/bretan/pt-optimize

This is not completely ready to ship but I haven't had time recently to fully finish it up.
The idea is that we ask each powertoy exactly which events it needs for SetWinEventHook.
This way we only register for the required events.
It is more efficient to have 30 hooks registered for the specific events necessary than it is to have 1 hook registered for a larger range of events. The overhead of having a bunch of hooks enabled to the kernel is minimal.
It also provides a callback to allow the powertoy a way to change which events it requires. This lets FZ only request EVENT_OBJECT_LOCATIONCHANGE while a drag is in progress.

Thanks @TheMrJukes this is a great improvement!
When you have time, can you give us your feedback on #961?
Thank you.

putting in 20.03, we may be able to pull this in sooner per @enricogior

I've rebased the branch to the current master (cherry-picked line by line manually, because every commit had a conflict almost in every file) and considered the proposed idea. It looks like we need to at least partially implement #961 for it to work, so I'm reestimating this a bit. What we need to do:

  • implement the ability to un/subscribe to a certain event dynamically for a certain toy
  • fix the way modules()/powertoys_events() work. currently it's trivial to create a race condition from using them (and we may already have one)
  • settle on the design of #961, so we don't do any incompatible features

To finish #961:

  • change the way we launch toys, so the events are always served from a particular thread
  • change the existing PT to accommodate with the updated event system (we can't have two versions of event system at the same time due to interface change and the way hooks work)

I've just finished drafting the design, but need to test some concepts, though it seems like a viable task for 0.16 nevertheless.

moving this toward 0.18 and 0.19 to wrap up. will be done with setting simplification work