NewPixelPainterBGRA: draw into a buffer that is not RGBA - #18
Merged
Conversation
A screen capture, a video frame and several native surfaces hand over BLUE, green, red, alpha. A consumer drawing widgets over one had two bad choices: swap the CAPTURE, which is the largest thing in the frame and the one part that must not be copied twice, or hand every colour in the theme over pre-swapped, which is dozens of values and one forgotten one away from a wrong colour nobody traces back. Swapping here costs two byte stores per pixel WRITTEN, and a widget writes a small part of a frame. Measured in go-xrkit/desk: its canvas holds BGRA because ScreenCaptureKit hands over BGRA and the frame is swapped once on the way to the window. Every overlay the toolkit drew into it -- the screen number, the gallery marks, the application tiles -- came out with red and blue exchanged, so the orange selection ring was BLUE on the glasses and nobody had noticed because the picture is only ever seen through a headset. All three paths that write a colour are covered: the fast opaque fill that builds one row and doubles it, an opaque pixel, and a translucent one that composites channel by channel.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A screen capture, a video frame and several native surfaces hand over blue, green, red, alpha. A consumer drawing widgets over one had two bad choices: swap the capture, which is the largest thing in the frame and the one part that must not be copied twice; or hand every colour in the theme over pre-swapped, which is dozens of values and one forgotten one away from a wrong colour nobody traces back.
Swapping here costs two byte stores per pixel written, and a widget writes a small part of a frame.
Measured
go-xrkit/desk's canvas holds BGRA, because ScreenCaptureKit hands over BGRA and the frame is swapped once on the way to the window (swapRB). Every overlay the toolkit drew into it — the screen number, the gallery marks, the application tiles — came out with red and blue exchanged:…and the orange selection ring was blue on the glasses. Nobody had noticed because that picture is only ever seen through a headset.
All three paths that write a colour are covered: the fast opaque fill that builds one row and doubles it, an opaque pixel, and a translucent one that composites channel by channel. Coverage stays at 100%;
-raceclean; linux and windows vet clean.