Core Graphics back-end #176
Conversation
cmyr
force-pushed
the
cg
branch
5 times, most recently
from
222dd59
to
681332f
Compare
There was a problem hiding this comment.
Generally looks good to me. It says I can't approve my own pull request, but feel free to approve and merge after addressing my concerns (also happy to discuss any open questions either here or in Zulip chat).
The situation around wrapped macOS types is deeply unsatisfying, what I propose here feels like an ok solution, but I would hope for improvement in the foundational libraries (difficult, though, without breaking existing clients).
| writer.write_image_data(cg_ctx.data()).unwrap(); | ||
| } | ||
|
|
||
| fn unpremultiply(data: &mut [u8]) { |
There was a problem hiding this comment.
Wondering about the duplication, whether it's possible to get this built with the png option. But also willing to accept that the Cargo feature plumbing would be too much of a pain :)
There was a problem hiding this comment.
Just not sure where it would live? I guess we could have some common-utils module or something in piet...
| CoreGraphicsContext::new_y_up(&mut cg_ctx, HEIGHT as f64 * SCALE.recip()); | ||
| piet::draw_test_picture(&mut piet_context, test_picture_number).unwrap(); | ||
| piet_context.finish().unwrap(); | ||
| std::mem::drop(piet_context); |
There was a problem hiding this comment.
Is unpremultiply not needed here as well?
There was a problem hiding this comment.
good point. What's a good way to rest the premultiplication? I don't really understand the tradeoffs here, or whether we even want to be using premultiplied alpha?
There was a problem hiding this comment.
In general, premultiplied is faster for rendering, but PNG stores only "separated." What I generally do for testing is render a large object with semi-transparency. For example, a white rectangle at 50% opacity will appear as gray if rendered as premultiplied and saved as png without correction.
| pub(crate) line_y_positions: Vec<f64>, | ||
| /// offsets in utf8 of lines | ||
| line_offsets: Vec<usize>, | ||
| pub(crate) frame_size: Size, |
There was a problem hiding this comment.
Note to self while reviewing: should this be a Rect rather than a Size, or can we always assume the origin is at zero?
There was a problem hiding this comment.
this is a size. It's hard to even say what origin means here, but in some sense it is at zero. (the drawing origin is the baseline of the first line, but we aren't given it explicitly)
cmyr
force-pushed
the
cg
branch
2 times, most recently
from
e541731
to
1b397f1
Compare
Still work in progress, but it draws and saves a PNG.
Still work in progress as images are not tested, but should be a start.
I actually consider the "unused" warnings to be useful, as they signal where implementation is needed, but grepping for "unimplemented" also works :)
This doesn't do hit testing, but it does paint multiline text.
This just makes our API cleaner? Ideally?
This involves stashing our source string, and generating a map to get utf8 offsets from utf16 offsets. This also adds stashing of line origins, which we will need for hit testing.
This is not currently extensively tested, and there may be some funny little things, but it gets us started.
This isn't well supported in the core-graphics crate, so we have to do a bit of our own FFI; there's a weird combination of traits and types used for FFI between the different core-foundation and core-graphics crates, and it was hard to get them to play nicely together, so this ends up throwing various aliases out the window for FFI.
And 'implement' status, which is apparently always peachy. This is the last bit of feature work; after this we'll just have fixups and getting geometry right etc.
This can execute the examples defined in piet-test.
These are small changes required to work with piet-common and druid.
Also includes other small manifest changes to get that all working.
This involves explicitly handling the different coordinate spaces between piet and coregraphics. I've chosen to be explicit; when creating a CoreGraphicsContext, you must either ask for y-up and pass in a height (so that we can apply a transform under the hood) or you can ask for y-down and handle conversion yourself (which plays nicely with Cocoa, and NSView.isFlipped.
This was just broken and not well enough tested.
Relying on CoreGraphics here causes problems from druid; because druid-shell for mac flips the coordinate system, there is a transform applied to the context before we see it that we want to ignore.
A bunch of small fixes. Larger things include: - reusing unpremultiply_rgba function - allowing explicit CGGradientDrawingOptions - better signatures in FFI
This is still work in progress. It's based off #4, updated for API changes and so on. In its current state, paths work and there is code for images, but nothing on gradients or text yet.