2019-05-03 00:29:04 +02:00
|
|
|
<?xml version="1.0" encoding="utf-8"?>
|
|
|
|
|
<Project DefaultTargets="Build" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
|
2019-11-05 23:29:11 +01:00
|
|
|
<PropertyGroup>
|
|
|
|
|
<ProjectGuid>{0CF235BD-2DA0-407E-90EE-C467E8BBC714}</ProjectGuid>
|
|
|
|
|
<Keyword>Win32Proj</Keyword>
|
|
|
|
|
<RootNamespace>bufferout</RootNamespace>
|
|
|
|
|
<ProjectName>BufferOut</ProjectName>
|
|
|
|
|
<TargetName>ConBufferOut</TargetName>
|
Greatly reduce allocations in the conhost/OpenConsole startup path (#8489)
I was looking at conhost/OpenConsole and noticed it was being pretty
inefficient with allocations due to some usages of std::deque and
std::vector that didn't need to be done quite that way.
So this uses std::vector for the TextBuffer's storage of ROW objects,
which allows one allocation to contiguously reserve space for all the
ROWs - on Desktop this is 9001 ROW objects which means it saves 9000
allocations that the std::deque would have done. Plus it has the
benefit of increasing locality of the ROW objects since deque is going
to chase pointers more often with its data structure.
Then, within each ROW there are CharRow and ATTR_ROW objects that use
std::vector today. This changes them to use Boost's small_vector, which
is a variation of vector that allows for the so-called "small string
optimization." Since we know the typical size of these vectors, we can
pre-reserve the right number of elements directly in the
CharRow/ATTR_ROW instances, avoiding any heap allocations at all for
constructing these objects.
There are a ton of variations on this "small_vector" concept out there
in the world - this one in Boost, LLVM has one called SmallVector,
Electronic Arts' STL has a small_vector, Facebook's folly library has
one...there are a silly number of these out there. But Boost seems like
it's by far the easiest to consume in terms of integration into this
repo, the CI/CD pipeline, licensing, and stuff like that, so I went with
the boost version.
In terms of numbers, I measured the startup path of OpenConsole.exe on
my dev box for Release x64 configuration. My box is an i7-6700k @ 4
Ghz, with 32 GB RAM, not that I think machine config matters much here:
| | Allocation count | Allocated bytes | CPU usage (ms) |
| ------ | ------------------- | ------------------ | -------------- |
| Before | 29,461 | 4,984,640 | 103 |
| After | 2,459 (-91%) | 4,853,931 (-2.6%) | 96 (-7%) |
Along the way, I also fixed a dynamic initializer I happened to spot in
the registry code, and updated some docs.
## Validation Steps Performed
- Ran "runut", "runft" and "runuia" locally and confirmed results are
the same as the main branch
- Profiled the before/after numbers in the Visual Studio profiler, for
the numbers shown in the table
Co-authored-by: Austin Lamb <austinl@microsoft.com>
2020-12-16 19:40:30 +01:00
|
|
|
<ConfigurationType>StaticLibrary</ConfigurationType>
|
2019-11-05 23:29:11 +01:00
|
|
|
</PropertyGroup>
|
2019-05-03 00:29:04 +02:00
|
|
|
<Import Project="$(SolutionDir)src\common.build.pre.props" />
|
|
|
|
|
<ItemGroup>
|
|
|
|
|
<ClCompile Include="..\AttrRow.cpp" />
|
|
|
|
|
<ClCompile Include="..\cursor.cpp" />
|
|
|
|
|
<ClCompile Include="..\OutputCell.cpp" />
|
|
|
|
|
<ClCompile Include="..\OutputCellIterator.cpp" />
|
|
|
|
|
<ClCompile Include="..\OutputCellRect.cpp" />
|
|
|
|
|
<ClCompile Include="..\OutputCellView.cpp" />
|
|
|
|
|
<ClCompile Include="..\Row.cpp" />
|
2019-11-14 23:36:41 +01:00
|
|
|
<ClCompile Include="..\search.cpp" />
|
2019-05-03 00:29:04 +02:00
|
|
|
<ClCompile Include="..\TextColor.cpp" />
|
|
|
|
|
<ClCompile Include="..\TextAttribute.cpp" />
|
|
|
|
|
<ClCompile Include="..\textBuffer.cpp" />
|
|
|
|
|
<ClCompile Include="..\textBufferCellIterator.cpp" />
|
|
|
|
|
<ClCompile Include="..\textBufferTextIterator.cpp" />
|
|
|
|
|
<ClCompile Include="..\CharRow.cpp" />
|
|
|
|
|
<ClCompile Include="..\CharRowCell.cpp" />
|
|
|
|
|
<ClCompile Include="..\CharRowCellReference.cpp" />
|
|
|
|
|
<ClCompile Include="..\precomp.cpp">
|
|
|
|
|
<PrecompiledHeader>Create</PrecompiledHeader>
|
|
|
|
|
</ClCompile>
|
|
|
|
|
<ClCompile Include="..\UnicodeStorage.cpp" />
|
|
|
|
|
</ItemGroup>
|
|
|
|
|
<ItemGroup>
|
|
|
|
|
<ClInclude Include="..\AttrRow.hpp" />
|
|
|
|
|
<ClInclude Include="..\cursor.h" />
|
|
|
|
|
<ClInclude Include="..\DbcsAttribute.hpp" />
|
|
|
|
|
<ClInclude Include="..\ICharRow.hpp" />
|
Add support for double-width/double-height lines in conhost (#8664)
This PR adds support for the VT line rendition attributes, which allow
for double-width and double-height line renditions. These renditions are
enabled with the `DECDWL` (double-width line) and `DECDHL`
(double-height line) escape sequences. Both reset to the default
rendition with the `DECSWL` (single-width line) escape sequence. For now
this functionality is only supported by the GDI renderer in conhost.
There are a lot of changes, so this is just a general overview of the
main areas affected.
Previously it was safe to assume that the screen had a fixed width, at
least for a given point in time. But now we need to deal with the
possibility of different lines have different widths, so all the
functions that are constrained by the right border (text wrapping,
cursor movement operations, and sequences like `EL` and `ICH`) now need
to lookup the width of the active line in order to behave correctly.
Similarly it used to be safe to assume that buffer and screen
coordinates were the same thing, but that is no longer true. Lots of
places now need to translate back and forth between coordinate systems
dependent on the line rendition. This includes clipboard handling, the
conhost color selection and search, accessibility location tracking and
screen reading, IME editor positioning, "snapping" the viewport, and of
course all the rendering calculations.
For the rendering itself, I've had to introduce a new
`PrepareLineTransform` method that the render engines can use to setup
the necessary transform matrix for a given line rendition. This is also
now used to handle the horizontal viewport offset, since that could no
longer be achieved just by changing the target coordinates (on a double
width line, the viewport offset may be halfway through a character).
I've also had to change the renderer's existing `InvalidateCursor`
method to take a `SMALL_RECT` rather than a `COORD`, to allow for the
cursor being a variable width. Technically this was already a problem,
because the cursor could occupy two screen cells when over a
double-width character, but now it can be anything between one and four
screen cells (e.g. a double-width character on the double-width line).
In terms of architectural changes, there is now a new `lineRendition`
field in the `ROW` class that keeps track of the line rendition for each
row, and several new methods in the `ROW` and `TextBuffer` classes for
manipulating that state. This includes a few helper methods for handling
the various issues discussed above, e.g. position clamping and
translating between coordinate systems.
## Validation Steps Performed
I've manually confirmed all the double-width and double-height tests in
_Vttest_ are now working as expected, and the _VT100 Torture Test_ now
renders correctly (at least the line rendition aspects). I've also got
my own test scripts that check many of the line rendition boundary cases
and have confirmed that those are now passing.
I've manually tested as many areas of the conhost UI that I could think
of, that might be affected by line rendition, including things like
searching, selection, copying, and color highlighting. For
accessibility, I've confirmed that the _Magnifier_ and _Narrator_
correctly handle double-width lines. And I've also tested the Japanese
IME, which while not perfect, is at least useable.
Closes #7865
2021-02-18 06:44:50 +01:00
|
|
|
<ClInclude Include="..\LineRendition.hpp" />
|
2019-05-03 00:29:04 +02:00
|
|
|
<ClInclude Include="..\OutputCell.hpp" />
|
|
|
|
|
<ClInclude Include="..\OutputCellIterator.hpp" />
|
|
|
|
|
<ClInclude Include="..\OutputCellRect.hpp" />
|
|
|
|
|
<ClInclude Include="..\OutputCellView.hpp" />
|
|
|
|
|
<ClInclude Include="..\Row.hpp" />
|
2019-11-14 23:36:41 +01:00
|
|
|
<ClInclude Include="..\search.h" />
|
2019-05-03 00:29:04 +02:00
|
|
|
<ClInclude Include="..\TextColor.h" />
|
|
|
|
|
<ClInclude Include="..\TextAttribute.h" />
|
|
|
|
|
<ClInclude Include="..\textBuffer.hpp" />
|
|
|
|
|
<ClInclude Include="..\textBufferCellIterator.hpp" />
|
|
|
|
|
<ClInclude Include="..\textBufferTextIterator.hpp" />
|
|
|
|
|
<ClInclude Include="..\CharRow.hpp" />
|
|
|
|
|
<ClInclude Include="..\CharRowCell.hpp" />
|
|
|
|
|
<ClInclude Include="..\CharRowCellReference.hpp" />
|
|
|
|
|
<ClInclude Include="..\precomp.h" />
|
|
|
|
|
<ClInclude Include="..\UnicodeStorage.hpp" />
|
|
|
|
|
</ItemGroup>
|
|
|
|
|
<!-- Careful reordering these. Some default props (contained in these files) are order sensitive. -->
|
|
|
|
|
<Import Project="$(SolutionDir)src\common.build.post.props" />
|
2021-01-20 22:16:56 +01:00
|
|
|
</Project>
|
