-
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
atlas,d2d: overdraw the background bitmap by one cell on all sides #17674
Conversation
BackendD2D will now draw one extra cell on all sides when rendering the background, filled with the expected background color, starting at (-1, -1) to ensure that cell backgrounds do not bleed over the edges of the viewport. Fixes #17672
The translation in `transform` ensures that we render it off the top left of the render target. | ||
*/ | ||
auto backgroundFill = std::make_unique_for_overwrite<u32[]>(static_cast<size_t>(size.width * size.height)); | ||
std::fill_n(backgroundFill.get(), size.width * size.height, u32ColorPremultiply(p.s->misc->backgroundColor)); |
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.
A heap alloc for 1440 bytes? At least it only happens when we need to recreate the bitmap.
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.
Thinking about it some more, you could use CreateCompatibleRenderTarget
and Clear()
to initialize the bitmap. There's some code you could copy in _resizeCursorBitmap
.
Another option is that we preallocate the foreground/background bitmap with a 1px margin and adjust the "stride" accordingly so that D3D is unaffected by this. The latter option is potentially the optimal solution, I think. (I'd be happy to help with that if you'd like.)
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.
Arguably more expensive than a heap alloc of 1440 bytes, FWIW.
A compatible render target, pointed to the bitmap, based on the current render target, all to just clear it (after converting the background color to D2D's preferred D2D_COLOR_F
) and suck the bitmap out to stride-copy the actual background colors in.
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.
However, preallocating it down in the Renderer is a good idea. Can we book that for the future, or would you like it in this PR?
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
BackendD2D will now draw one extra cell on all sides when rendering the background, filled with the expected background color, starting at (-1, -1) to ensure that cell backgrounds do not bleed over the edges of the viewport where the is swapchain but no content. Fixes #17672 (cherry picked from commit 9007fc2) Service-Card-Id: 93494324 Service-Version: 1.21
BackendD2D will now draw one extra cell on all sides when rendering the background, filled with the expected background color, starting at (-1, -1) to ensure that cell backgrounds do not bleed over the edges of the viewport where the is swapchain but no content.
Fixes #17672