-
Notifications
You must be signed in to change notification settings - Fork 8.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reduce cost of cursor invalidation #15500
Changes from 1 commit
7aa3731
4da71ff
0600f08
ec7ceb8
7cae3c5
47ef6e7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -217,11 +217,6 @@ namespace winrt::Microsoft::Terminal::Control::implementation | |
ControlCore::~ControlCore() | ||
{ | ||
Close(); | ||
|
||
if (_renderer) | ||
{ | ||
_renderer->TriggerTeardown(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. no longer need to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sort of. The destructor blocks until the renderer is fully shut down, which is similar to I'll re-add the explicit destructor calls here just to be sure nothing regresses. We use a lot of plain/unsafe pointers after all. |
||
} | ||
} | ||
|
||
void ControlCore::Detach() | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the right hand side may be off by one when you're dealing with exclusive coordinates with an odd value. For example, if the right screen coordinate is 7 exclusive (6 inclusive), that should map to a buffer coordinate of 4 exclusive (3 inclusive). A simple right shift works for inclusive coordinates (
6 >> 1 = 3
), but not for exclusive coordinates (7 >> 1 = 3
, but we want 4).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... I think the current approach is valid as well, in a certain way. Currently, these two related functions round down the width of the buffer:
TextBuffer::GetLineWidth
ROW::GetReadableColumnCount
If this function where to round up the
right
coordinate, then passing a viewport sizedtil::rect
will end up having a different size than the size reported by the above two functions.I do prefer your suggestion, but do we need to change other code first before we can round exclusive coordinates up here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I guess this means we've had this inconsistency for a while right? Because the
inclusive_rect
variant ofScreenToBufferLine
may have reported an inclusive.right
of 59 while the above two functions reported a max. width of 59. Hmm... I'm not sure how to best resolve this.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think they're expected to be inconsistent.
GetLineWidth
tells you how many buffer columns you can fit on the screen, so it has to round down if only half of the last column will fit. ButScreenToBufferLine
is used to determine how much of the buffer is required to cover a given screen area. If you round down, you won't get enough buffer content, and the last screen cell won't be updated.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, yeah I see what you mean. However, I'm also a little squirmish about what you said. This function isn't used anywhere yet and so I'll remove it for now and we can revisit it later. 🙂
Idle thoughts: Personally speaking, I would prefer if we could consistently use
til::rect
with its exclusive coordinates everywhere, even in areas of our code where inclusive coordinates would be a better fit, just so that everything works consistently. I wonder if this issue would go away with such a change as well... Probably not really, but it may still avoid some potential for confusion.