feat: Add render_to_pixmap_at_offset for spritesheet support#1416
Conversation
|
I think this would also solve #1382 |
nicoburns
added
enhancement
Yeah, that sounds very applicable to that case. I also think it could be useful for #1130 as well. In my case, it’s purely about populating the atlas glyph pixmap so it can be used later for rendering purposes. The next PR I’m preparing after this one will add support for such spritesheets in vello_cpu. |
| /// | ||
| /// This is useful for rendering individual elements (like glyphs) into | ||
| /// a spritesheet at specific coordinates. | ||
| pub fn render_to_pixmap_at_offset(&self, pixmap: &mut Pixmap, dst_x: u16, dst_y: u16) { |
There was a problem hiding this comment.
Two things:
- We need to add a big fat warning that this will panic in multi-threaded mode. 😄
- I think it's not ideal that this method has the same name as
render_to_pixmap, even though they do different things (one will replace the pixmap, anther one will composite it on top of existing content). Maybe we should rename it tocomposite_onto_pixmap_at_offsetor something?
There was a problem hiding this comment.
This also applies to all other usages as well as some of the related methods (i.e. the internal rasterize_at_offset methods).
There was a problem hiding this comment.
I agree with both comments.
Fixed.
| let wtile = self.wide.get(x, y); | ||
| fine.set_coords(x, y); | ||
|
|
||
| fine.unpack(region); |
There was a problem hiding this comment.
Maybe add a small comment that this achieves the effect of compositing onto the existing contents of a pixmap, instead of replacing it.
grebmeg
force-pushed
the
gemberg/render_to_pixmap_at_offset
branch
from
79f5520 to
a1b5b90
Compare
| /// | ||
| /// This method is only supported with the single-threaded dispatcher and will | ||
| /// **panic** if called on a `RenderContext` using the multi-threaded dispatcher. | ||
| pub fn composite_to_pixmap_at_offset(&self, pixmap: &mut Pixmap, dst_x: u16, dst_y: u16) { |
There was a problem hiding this comment.
In future, Same approach for working with direct buffer would be like:
pub fn composite_to_buffer_at_offset(
&self,
buffer: &mut [u8],
width: u16,
height: u16,
dst_x: u16,
dst_y: u16,
) { ... }4 participants
Add the ability to render a
RenderContext's content directly into a sub-region of a larger pixmap at a specified (x, y) offset. The method composites on top of existing content rather than clearing, allowing multiple renders to accumulate.This is useful for building spritesheets where individual elements (like glyphs) are rendered to specific coordinates without intermediate buffer allocation.
An example test result from this PR:
