Port vello_editor example to vello_cpu + rename to just editor - #669
Conversation
| builder.fill_glyphs(glyph_run.positioned_glyphs().map(|glyph| Glyph { | ||
| id: glyph.id, | ||
| x: glyph.x, | ||
| y: glyph.y, | ||
| })); |
There was a problem hiding this comment.
Switching from glyph_run.glyphs() (+manually computing positions) to glyph_run.positioned_glyphs() was a drive-by change from the LLM, but a good one so I've kept it.
DJMcNab
left a comment
DJMcNab
left a comment
There was a problem hiding this comment.
I've not ran this yet. On a first pass, the set_brush function feels like a massive code smell; it isn't obvious to me why the 'just always pass a color around' and/or pass a Vello CPU paint around were so unviable that this was the best option.
| if let (Some(width), Some(height)) = | ||
| (NonZeroU32::new(size.width), NonZeroU32::new(size.height)) | ||
| { | ||
| render_state.surface.resize(width, height).unwrap(); | ||
| } | ||
| self.handle_resize(to_nonzero_u16(size.width), to_nonzero_u16(size.height)); |
There was a problem hiding this comment.
Are you sure that this still works when the window is minimised (so the surface doesn't get resized but the render context does...)
There was a problem hiding this comment.
Hmm... we probably just need to make sure it doesn't render in that case.
There was a problem hiding this comment.
Testing locally on macOS, minimising seems to work fine.
There was a problem hiding this comment.
That's not a huge surprise; the thing which needs to be checked is how it handles on Windows. I believe that minimising on macOS doesn't change the window size.
It's possible that this has changed on recent winits?
I no longer have a windows machine, so can't test this easily.
| renderer.set_stroke(Stroke::new(width.into())); | ||
| set_brush(renderer, &style.brush); | ||
| renderer.stroke_path(&line.to_path(0.0)); |
There was a problem hiding this comment.
There are arguments for using ink skipping underline here, but that's non-blocking.
There was a problem hiding this comment.
We need to wait for a vello_cpu for this, then it will be trivial :)
I had exactly the same thought. And the answer is that |
|
I think using a newtype is probably the best option, as it's a similar amount of code, but more accurately reflects the state of the feature. |
2e4be04 to
282bad1
Compare
|
Updated to a newtype around |
|
Video evidence that this does not crash when minimised on Windows is attached. This was generated automatically by an AI running in a VM: rec-2234d1ca-9fcb-44fb-a798-4452018740d7-edited.mp4 |
Signed-off-by: Nico Burns <nico@nicoburns.com>
Signed-off-by: Nico Burns <nico@nicoburns.com>
Signed-off-by: Nico Burns <nico@nicoburns.com>
b58de34 to
2c03483
Compare
2 participants
Extracted from #662.
Ports the
vello_editorexample to usevello_cpuinstead ofvello. This actually makes things quite a bit simpler as we avoid having to deal with all of the WGPU setup code.