On Jun 27, 2020, at 8:30 AM, Robert Engels <reng...@ix.netcom.com> wrote:
> Just because the bulk of the time is in the decode doesn’t mean the decode is 
> inefficient or can be improved upon. It might be the most expensive stage in 
> the process regardless of the implementation. 

This is I think the most important point; image decoding is an expensive 
operation, and it makes sense that the bulk of your time decoding is spent on 
it.  The question is how it stacks up to other decoders; if you're able to 
write a quick C proof-of-concept to test how fast libpng does it (or libspng) 
and run the same benchmarks, you'll get your answer there.

Depending on how regular your images are (size-wise, especially), you may be 
able to get some additional mileage out of pooling your receiving buffers and 
reusing them after your operations are complete. There doesn't appear to be a 
handle for that in the current image/png library like there is for encoding, 
though; you'd have to do some surgery on decoder.readImagePass to do something 
like that.

- Dave

You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to