Conversation
|
I see no updates since long ago in your repository. Do you think I could help you maintain it ? |
|
Hey thanks for the PR and sorry for the late reply. I like the idea of passing a closure or a trait implementation to let the user decide how to handle the incoming pixels, that could open the API up to use more of a streaming approach. I'm less sure of some of the embedded-graphics specific code in this PR though, I don't think things like So in general, I'm in favor of making the API more flexible if it helps you integrate embedded graphics, but they should be flexible enough that they don't need to pull in embedded-graphics as a direct dependency, if that makes sense. |
I'd prefer to keep things as-is for now. I may not be super responsive as my open source projects are just maintained as a hobby, but I do get around to stuff eventually. |
|
I made |
|
On a second thought, I think I can do that, create a new crate. |
b50962e to
c8b187b
Compare
|
|
||
| let mut compressed_data: Vec<u8> = | ||
| Vec::with_capacity(header.width as usize * header.height as usize * 3); | ||
| let mut compressed_data: Vec<u8> = Vec::new(); |
There was a problem hiding this comment.
This is compressed data, creating it with uncompressed size is wasteful
|
Here it is. Please read with w=1 since github doesn't handle moved code very well. |
Hi,
I found your crate useful for embedded because it is simple and doesn't use simd.
Here is a patch to implement what is needed to make is embedded-graphics compatible.
What do you think ?