[vello_cpu] Add a draw_pixmap
method
#1256
Draft
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 motivation for this is two-fold:
Currently, the only way to draw an image is by drawing a rectangle with a pattern fill. If you know how to do it, you know it, but this is probably not the most intuitive way (as can be seen in [vello_cpu] How to draw pixmap on a pixmap? #1130). Because of this, I think it's a good idea to add an explicit
draw_pixmap
method that can be called by the user, which should be much more clear.Currently, there is the problem that we have to define an extend for images, which makes sense for patterns but not necessarily for just drawing a single image. For example, I encountered the situation where when drawing a very small bitmap glyph using bilinear/biubic interpolation, it will basically look like a black block, because when sampling pixels outside we will apply an extend instead of sampling a transparent pixel, which would make more sense:
Because of this, when drawing an image we add a new mode that applies no extend at all and samples transparent pixels when going oob. This makes the letter a look nicer (the V looks a bit funky for different reasons):

This does have some impact on performance when rendering normal patterns (left is before, right after), but nothing that I would consider very too serious. The other option would be to introduce generic parameters, but that would make our already very generics-heavy code even more heavy, so I'd like to avoid that.