-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Add support for the rectangular area operations #14285
Conversation
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.
Looks good to me! Thanks!
Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
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.
LGTM, but I did have an idea...
Hello @lhecker! Because this pull request has the 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 (
|
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.
Outstanding as always. Thanks James!
🎉 Handy links: |
## Summary of the Pull Request There are certain escape sequences that use the `VTParameters::subspan` method to access a subsection of the provided parameter list. When the parameter list is empty, that `subspan` call can end up using an offset that is out of range, which causes the terminal to crash. This PR stops that from happening by clamping the offset so it's in range. ## References and Relevant Issues This bug effected the `DECCARA` and `DECRARA` operations introduced in PR #14285, and the `DECPS` operation introduced in PR #13208. ## Validation Steps Performed I've manually confirmed that the sequences mentioned above are no longer crashing when executed with an empty parameter list, and I've added a little unit test that checks `VTParameters::subspan` method is returning the expected results when passed an offset that is out of range. ## PR Checklist - [x] Closes #15234 - [x] Tests added/passed - [ ] Documentation updated - [ ] Schema updated (if necessary)
## Summary of the Pull Request There are certain escape sequences that use the `VTParameters::subspan` method to access a subsection of the provided parameter list. When the parameter list is empty, that `subspan` call can end up using an offset that is out of range, which causes the terminal to crash. This PR stops that from happening by clamping the offset so it's in range. ## References and Relevant Issues This bug effected the `DECCARA` and `DECRARA` operations introduced in PR #14285, and the `DECPS` operation introduced in PR #13208. ## Validation Steps Performed I've manually confirmed that the sequences mentioned above are no longer crashing when executed with an empty parameter list, and I've added a little unit test that checks `VTParameters::subspan` method is returning the expected results when passed an offset that is out of range. ## PR Checklist - [x] Closes #15234 - [x] Tests added/passed - [ ] Documentation updated - [ ] Schema updated (if necessary) (cherry picked from commit e413a41) Service-Card-Id: 89001985 Service-Version: 1.17
Summary of the Pull Request
This PR adds support for the rectangular area escape sequences:
DECCRA
,DECFRA
,DECERA
,DECSERA
,DECCARA
,DECRARA
, andDECSACE
. They provide VT applications with an efficient way to copy,fill, erase, or change the attributes in a rectangular area of the
screen.
PR Checklist
where discussion took place: Add support for the rectangular area operations #14112
Detailed Description of the Pull Request / Additional comments
All of these operations take a rectangle, defined by four coordinates.
These need to have defaults applied, potentially need to be clipped
and/or clamped within the active margins, and finally converted to
absolute buffer coordinates. To avoid having to repeat that boilerplate
code everywhere, I've pulled that functionality out into a shared method
which they all use.
With that out of the way, operations like
DECFRA
(fill),DECERA
(erase), and
DECSERA
(selective erase) are fairly simple. They're justfilling the given rectangle using the existing methods
_FillRect
and_SelectiveEraseRect
.DECCRA
(copy) is a little more work, because wedidn't have existing code for that in
AdaptDispatch
, but it's mostlyjust cloned from the conhost
_CopyRectangle
function.The
DECCARA
(change attributes) andDECRARA
(reverse attributes)operations are different though. Their coordinates can be interpreted as
either a rectangle, or a stream of character positions (determined by
the
DECSACE
escape sequence), and they both deal with attributemanipulation of the target area. So again I've pulled out that common
functionality into some shared methods.
They both also take a list of
SGR
options which define the attributechanges that they need to apply to the target area. To parse that data,
I've had to refactor the
SGR
decoder from theSetGraphicsRendition
method so it could be used with a given
TextAttribute
instance insteadof just modifying the active attributes.
The way that works in
DECCARA
, we apply theSGR
options to twoTextAttribute
instances - one with all rendition bits on, and one withall off - producing a pair of bit masks. Then by
AND
ing the targetattributes with the first bit mask, and
OR
ing them with the second, wecan efficiently achieve the same effect as if we'd applied each
SGR
option to our target cells one by one.
In the case of
DECRARA
, we only need to create a single bit mask toachieve the "reverse attribute" effect. That bit mask is applied to the
target cells with an
XOR
operation.Validation Steps Performed
Thanks to @KalleOlaviNiemitalo, we've been able to run a series of tests
on a real VT420, so we have a good idea of how these ops are intended to
work. Our implementation does a reasonably good job of matching that
behavior, but we don't yet support paging, so we don't have the
DECCRA
ability to copy between pages, and we also don't have the concept of
"unoccupied" cells, so we can't support that aspect of the streaming
operations.
It's also worth mentioning that the VT420 doesn't have colors, so we
can't be sure exactly how they are meant to interpreted. However, based
on the way the other attribute are handled, and what we know from the
DEC STD 070 documentation, I think it's fair to assume that our handling
of colors is also reasonable.