| 10 Jan 2020 |
 rfuest | The changes I suggested in #229 were also in preparation for adding a clean interface for features like accessing pixels | 00:03:17 |
 jacobrosenthal | ohho really | 00:03:28 |
 jamwaffles | So add X/Y getters to tinybmp/tinytga and add wrapper methods inside e-g? | 00:04:18 |
| jamwaffles | In reply to @jacobrosenthal:matrix.org
the idea is definately a no_std tiny version, and then const fn I hadn't even thought of const fn images. That's bitchin. | 00:04:46 |
| jacobrosenthal | I dont think we can include_bytes or fs::read or whatever, but that will be amazing when we can | 00:06:10 |
| jacobrosenthal | to me thats the beauty of const fn, all that make file and excel calculations for registers and type bullshit currently kept out of code finally comes back home | 00:07:40 |
| rfuest | An ImageData trait in e-g that can be implemented by external crates and also the internal raw support. ImageData can then be converted into an Iter or provide other functions like get_pixel. | 00:08:07 |
| rfuest | I have played with using a procedural macro to convert images in the past and I think that would work similar to include_bytes!(). | 00:08:58 |
| jamwaffles | Does it need to be another trait? Why not have each image crate impl IntoIterator<Item = PixelColor<C>>? | 00:10:02 |
| rfuest | ImageData could provide other functions like size or get_pixel | 00:10:30 |
| jamwaffles | Sure, but if the e-g "integration" is moving into each image crate, why not have size(), etc in those crates? | 00:10:58 |
| jamwaffles | Depends how loose you want the e-g integration to be I guess? | 00:11:14 |
| rfuest | Sure that is something that needs to be considered. But having some features in the ImageData trait provides a generic interface to all kinds of images. | 00:15:15 |
| rfuest | This was more code could be reused. If we, for example, decide to implement scaled drawing inside the Image struct all crates implementing ImageData could be scaled as well. | 00:17:05 |
| rfuest | s/was/way/ | 00:17:20 |
| jamwaffles | Hypothetical case: I have an embedded JPEG image lib that only has an iterator based interface which does a lot of expensive JPEG decoding on the fly. If ImageData requires a get_pixel() method, my super expensive iterator has to run through to find the right pixel and return it every time get_pixel() is called. I'd rather not require lib authors to fully implement something like ImageData, hence the requirement of Intoiterator<Item = PixelColor<C>> above instead. | 00:20:51 |
| rfuest | Good point, the interface could be split into multiple traits: ImageData which just provides the image size and a way to get an pixel iterator and PixelAdressableImageData which provides get_pixel. | 00:27:59 |
| jamwaffles | Let's start simple and go with just Intoiterator<Item = PixelColor<C>> for now. tinytga/tinybmp can be refactored to integrate that way (as mentioned in #229). Other image traits can always be added later if someone starts complaining that e-g doesn't have them. | 00:30:14 |
| jamwaffles | It's not so bad leaving each image crate to its own impl concerning getting pixels, etc. I'm ok letting the reusability slide in this respect (at least for the time being) | 00:31:26 |
| jamwaffles | I want to release 0.6.0 (non alpha) soon which won't happen if we let all these features creep in 😄 | 00:32:10 |
| jamwaffles | I gotta split unfortunately. Way past my bedtime. I like the approach posted in #229 about "reversing" the tinybmp/tga integrations but I don't want to go much further than that | 00:32:59 |
| jamwaffles | Later! | 00:33:10 |
| rfuest | Bye | 00:33:20 |
| 11 Jan 2020 |
|  hylian joined the room. | 09:09:20 |
| jamwaffles | Redacted or Malformed Event | 20:25:14 |
| jamwaffles | rfuest: after #224, is there anything else breaking in the issue list we should put in before doing another 0.6.0-alpha release? | 20:25:46 |
| jamwaffles | The issues in the list currently all seem to be additive and non-breaking, so should let future alpha/beta releases settle a bit with fewer breaking changes | 20:26:50 |
| rfuest | The reversing of the tinytga and tinytga crates would be breaking for users of the bmp and tga features. But other than that I don't see any mayor breaking changes that should go into the 0.6 release. | 20:30:04 |
| jamwaffles | True. Those should go in 0.6 though, but the next alpha | 20:30:57 |
| rfuest | I agree. How do you plan to continue after the next alpha release? I would suggest to handle the code changes #211, #229, #238, #239 first and then release a beta. The beta shouldn't get any bigger code changes, if no problems occur, and only doc improvements. | 20:47:49 |
