-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New public API pub fn expand_interlaced_row
#495
New public API pub fn expand_interlaced_row
#495
Conversation
Example code that depends on the new API can be seen in http://review.skia.org/894576 |
40bf4e3
to
f6eadd4
Compare
This helps with the following things: * It means that after making `InterlaceInfo` public in a follow-up commit, `pass`, `line`, and `width` fields can remain private. * It means that a follow-up commit that refactors `adam7::expand_pass` to take a single `info` parameter doesn't allow passing an invalid `InterlaceInfo::Null` value. * It gives `Adam7Iterator` a nicer, named `Iterator::Item`.
Instead of passing `line_no` and `pass` as separate parameters, we can pass a single `&Adam7Info` parameter. This minor refactoring helps with: * Exposing a nice public API in a follow-up commit * Depending on `Adam7Info.width` in a follow-up commit
Instead of passing `line_no` and `pass` as separate parameters, we can pass a single `&Adam7Info` parameter. This minor refactoring helps with: * Cleaning up `fn expand_pass` by moving some of its complexity closer to where its needed (within `fn expand_adam7_bits`) * Preparing for changing the semantics of the `width` parameter of `fn expand_adam7_bits` in a follow-up commit, where we will stop depending on `width` for calculating the length of the returned iterator (depending on `Adam7Info.width` instead). See the follow-up commit for more details.
This commit refactors implementation of `expand_adam7_bits` so that it can accept `row_stride_in_bytes` that is different from the expanded width of the frame or image. This is helpful for making `expand_pass` work in scenarios where interlaced row needs to expanded into a bigger image (e.g. if the currently decoded frame is an animation frame that only takes a subregion of the whole image - in this case the stride between expanded rows is bigger than the size of expanded rows). And the above is helpful for exposing `expand_pass` through a public API that will hopefully pass the test of time...
This also exposes supporting items through the public API: `Adam7Info`, `InterlaceInfo`, `InterlacedRow`.
f6eadd4
to
ac04cd3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, let's run with this.
Can you please hold off with publishing a new version of the This PR adds I'll try to push new commits/changes to the other PR today or tomorrow. |
This is a clean-up / follow-up for http://review.skia.org/889877 where we implemented `onIncrementalDecode` but only for non-interlaced images. Note that this CL depends on new public APIs in the `png` crate (ones that are not yet present in `png-0.17.13`). Therefore this CL depends on having a post-0.17.3 crate version when building `FFI.rs`: * In the short-term this dependency is fulfilled by patching the crate in https://crrev.com/c/5825297 * In the long-term this dependency will be met by a new release of the `png` crate (the PR at image-rs/image-png#495 hasn't been released yet). Bug: chromium:356923435 Change-Id: I2787c2f5a9b256720e779ea0acc8737c87cee2c3 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/894576 Commit-Queue: Łukasz Anforowicz <lukasza@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
Currently users of
Reader.next_interlaced_row
can't handle interlaced rows without re-implementing significant chunks of thepng
crate. This PR resolves this by exposing a new public API:pub fn expand_interlaced_row
+pub enum InterlaceInfo
.