Reduce clipping memory usage and allocation #920
+5
−4
Conversation
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
The scratch strip buffer may be quite large when the render context has been used for rendering complex paths. If the clip geometry is simple, storing that buffer in the clip state has two downsides: - the buffer will have unused capacity, inflating the memory footprint of the renderer, - as the buffer is moved into the clip state, a new buffer has to be allocated, and for subsequent rendering of complex paths will have to grow large again. This PR proposes keeping the original allocation for the scratch strip buffer and memcpy'ing the clip's strips to a new allocation of the right size. (As a side-effect the size of the `Clip` struct is reduced from 40 to 32 bytes.) There are alternatives: the first downside could be alleviated by a `shrink_to_fit`, and allocator thrashing of the second downside could be reduced by allocating the new buffer with the same capacity as the old buffer. It's probably better to just keep the original allocation for the scratch buffer, though.
LaurenzV
approved these changes
Apr 18, 2025
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
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.
The scratch strip buffer may be quite large when the render context has been used for rendering complex paths. If the clip geometry is simple, storing that buffer in the clip state has two downsides:
This PR proposes keeping the original allocation for the scratch strip buffer and memcpy'ing the clip's strips to a new allocation of the right size. (As a side-effect the size of the
Clipstruct is reduced from 40 to 32 bytes.)There are alternatives: the first downside could be alleviated by a
shrink_to_fit, and allocator thrashing of the second downside could be reduced by allocating the new buffer with the same capacity as the old buffer. It's probably better to just keep the original allocation for the scratch buffer, though.