Fix missing call to UpdateViewport::UpdateViewport during tearout #15175
Conversation
lhecker
added
Area-Rendering
| @@ -638,6 +638,7 @@ void Renderer::EnablePainting() | |||
| // When the renderer is constructed, the initial viewport won't be available yet, | |||
| // but once EnablePainting is called it should be safe to retrieve. | |||
| _viewport = _pData->GetViewport(); | |||
| _forceUpdateViewport = true; | |||
There was a problem hiding this comment.
(silmarillion) moving a tab to a larger window doesn't resize the control - THIS WAS AN ATLAS BUG
So, as it turns out, it's actually a DxRenderer bug which just happens to mask the other bug in Renderer, fixed here. 😄
DxRenderer doesn't use the IRenderEngine::UpdateViewport function. UpdateViewport was probably intended originally to tell the renderer the size of the text buffer.
It just happens to not cause any harm to Windows Terminal specifically, because it calls IRenderEngine::SetWindowSize and Terminal::UserResize while holding the console lock across both calls. So the renderer size and text buffer size always stay in sync. This isn't true for conhost though which uses an asynchronous approach to window resizing: The text buffer is resized on the window message thread, while the renderer thread is "free running" and only gets the current window size when it decides to paint. But by that point the window size might be different from the text buffer size.
This causes DxRenderer to crash with a SIGSEGV when you resize the OpenConsole window too quickly.
| @@ -131,7 +131,7 @@ namespace Microsoft::Console::Render | |||
| std::function<void()> _pfnFrameColorChanged; | |||
| std::function<void()> _pfnRendererEnteredErrorState; | |||
| bool _destructing = false; | |||
| bool _forceUpdateViewport = true; | |||
| bool _forceUpdateViewport = false; | |||
There was a problem hiding this comment.
this also scares me, since it impacts GDI and WDDM and BGFX!
There was a problem hiding this comment.
It’s more correct however since the only reason this member exists is because EnablePainting overwrites _viewport which it absolutely should not do. There’s no guarantee that the IRenderData has a valid viewport at that point. Because it overwrites _viewport we need this Boolean to ensure UpdateViewport is called anyways. So in a sense this is more correct because it puts the overwrite to where the mistake is happening in the first place.
|
Gonna check this out locally and test it, but yea I'm curious how not needing to re-enable painting is just... fine |
|
Mmmmmm. it's probably cause of
|
zadjii-msft
added
the
AutoMerge
Co-authored-by: Dustin L. Howett <duhowett@microsoft.com>
microsoft-github-policy-service
bot
deleted the
dev/lhecker/14957-fix-resize-glitch
branch
This bug causes AtlasEngine to render buffer contents with an incorrect
cellCount, which may either cause it to draw the contents onlypartially, or potentially access the TextBuffer contents out of bounds.
EnablePaintingsets the_viewportto the current viewport for someunfortunate (and quite buggy/incorrect) caching purposes, which causes
_CheckViewportAndScroll()to think that the viewport hasn't changedin the new window. We can ensure
_CheckViewportAndScroll()worksby also setting
_forceUpdateViewporttotrue.Part of #14957
PR Checklist