WIP: macos: Copy to IOSurface on present #96
Draft
Conversation
This file contains 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
It looks like `BytesPerRow` (the stride) has some kind of alignment requirement (testing on M1), that doesn't let us just use the width. So for this to work, softbuffer needs to expose the stride, and the user needs to deal with that... This doesn't seem to be showing the right thing even when width matches stride. Not sure why.
Division is more expensive than multiplication, and this doesn't seem to be optimize away, so iterating over `(0..height)` and `(0..width)` provides better performance. It's good to have the example show the best way to write code using softbuffer, and this helps when using examples as a benchmark. This will also be needed if Softbuffer supports formats where `stride` isn't just `width * pixel_size`, and needs alignment.
|
Interesting, the main time overhead on the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Alternative to #95, that avoids API changes.
In a release build on an M1 mac, fullscreened at 1440p, this brings the
animationexamples redraw time from about 10ms to 900μs. But thewinitexample ends up increasing to 20ms from around 18ms. This does include resizing time, but seems to still take at least a ms more even excluding that?#95 does improve the
winitexample here to 12ms, but gets 1.25ms foranimation(that's probably since it currently allocates anIOBufferevery single present, so it could be fixed by doing that correctly).Interesting how this version compares. There is also likely some overhead to the previous version this test isn't catching (When does it actually copy from the
CGDataProviderto GPU? Is that later in our main loop, or does the display server handle that?).