Skip to content

Defer cursor winrt event triggering - #10685

Merged
2 commits merged into
microsoft:mainfrom
skyline75489:chesterliu/dev/cursor-winrt
Jul 20, 2021
Merged

2 commits merged into
microsoft:mainfrom
skyline75489:chesterliu/dev/cursor-winrt

Conversation

@skyline75489

@skyline75489 Chester Liu (skyline75489) commented Jul 16, 2021 •

Copy link
Copy Markdown
Collaborator

Summary of the Pull Request

References

PR Checklist

  • Supports [Performance] vtebench tracking issue #10563
  • CLA signed. If not, go over here and sign the CLA
  • Tests added/passed
  • Documentation updated. If checked, please file a pull request on our docs repo and link it here: #xxx
  • Schema updated.
  • I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

@skyline75489

Copy link
Copy Markdown
Collaborator Author

The winrt event is shockingly expensive...

Before:

image

After:

image

@lhecker

Copy link
Copy Markdown
Member

Love it! Just a quick question: Is this thread safe? (I'm unfamiliar with the Cursor class.)

Also I believe it's kind of backwards that we use a ThrottledFunc for this. In my opinion we should add a "BeginDraw" and "EndDraw" event to our renderers, which could be used to do changes like this (updating TSFInputControl) in V-Sync without lagging behind.

@miniksa

Copy link
Copy Markdown
Contributor

I find it weird that we have to avoid sending this on the sender side and aren't appropriately coalescing or discarding the additional notifications on the receiving side. But I'm willing to take whatever works.

In my opinion we should add a "BeginDraw" and "EndDraw" event to our renderers,

Leonard Hecker (@lhecker), last I checked... the renderers DO have a Begin and End draw sort of thing... can you clarify further what you mean?

@lhecker

Copy link
Copy Markdown
Member

Michael Niksa (@miniksa) An eventing system based on when the renderer draws, allows us to keep any other UI modifications in sync. For instance instead of using a throttled func, we could hook into the render loop using events and update the scrollbar in sync with when the renderer pushes pixels on the screen, without having to use any additional timers for that.

@skyline75489

Copy link
Copy Markdown
Collaborator Author

I don’t actually know if there’s a way to disable the event completely on the receiver side. We already have throttle_func as sort of “disabling” it, but that’s not good enough. The WinRt event is just so expensive that we can’t afford.

I think Leonard Hecker (@lhecker)’s idea is actually how UI framework usually works, for example that’s basically how “Runloop” in iOS works. The problem here is that we have two independent “framework” here, one being the DxRenderer and related, the other being XAML. And the main way for them to communicate was through WinRT events. I see this as another consequence of tight-coupling of renderer.cpp (where the render thread lives) and DxEngine. After #10615 (seriously guys, take a look and you can see how effective that PR is) and future PR lands, we should be able to use the “hooking into the render thread” way to do something interesting. Of course the UI thread limitation in XAML still need to be taken into consideration.

@miniksa

Copy link
Copy Markdown
Contributor

After #10615 (seriously guys, take a look and you can see how effective that PR is) and future PR lands

Dude its in my queue, it's just a big deal so I've been procrastinating. I feel seen. (I plan to look Monday... you're just catching me feeling too sleepy to ponder long term consequences...)

@miniksa

Copy link
Copy Markdown
Contributor

I don’t actually know if there’s a way to disable the event completely on the receiver side. We already have throttle_func as sort of “disabling” it, but that’s not good enough. The WinRt event is just so expensive that we can’t afford.

OK well I'm willing to take this until we get further along if it helps this much. Just leave commentary.

@zadjii-msft Mike Griese (zadjii-msft) added Area-Performance Performance-related issue Product-Terminal The new Windows Terminal. labels Jul 19, 2021
@zadjii-msft Mike Griese (zadjii-msft) added the AutoMerge Marked for automatic merge by the bot when requirements are met label Jul 20, 2021
@ghost

Copy link
Copy Markdown

Hello Mike Griese (@zadjii-msft)!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost
ghost merged commit fb69aec into microsoft:main Jul 20, 2021
@skyline75489
Chester Liu (skyline75489) deleted the chesterliu/dev/cursor-winrt branch August 27, 2021 02:42
@ghost

Copy link
Copy Markdown

🎉Windows Terminal Preview v1.11.2421.0 has been released which incorporates this pull request.:tada:

Handy links:

ghost pushed a commit that referenced this pull request Jan 25, 2022
I can find the commit where this regressed tomorrow if needed. In #10685 we stopped emitting these notifications while we were deferring cursor drawing. We however forgot to send the notification at the end of the defer.

This likely has a small perf impact. We however do need these cursor position events for IMEs to be able to track the cursor position (and low key for #10821)

* [x] regressed in #10685
* [x] Closes #11170
* [x] I work here
* [x] Tests added
Dustin L. Howett (DHowett) pushed a commit that referenced this pull request Jan 31, 2022
I can find the commit where this regressed tomorrow if needed. In #10685 we stopped emitting these notifications while we were deferring cursor drawing. We however forgot to send the notification at the end of the defer.

This likely has a small perf impact. We however do need these cursor position events for IMEs to be able to track the cursor position (and low key for #10821)

* [x] regressed in #10685
* [x] Closes #11170
* [x] I work here
* [x] Tests added

(cherry picked from commit 01fd714)
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area-Performance Performance-related issue AutoMerge Marked for automatic merge by the bot when requirements are met Product-Terminal The new Windows Terminal.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants