Skip to content
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

spng_decode_row and spng_decode_scanline are bad APIs #205

Open
quintopia opened this issue Feb 3, 2022 · 1 comment
Open

spng_decode_row and spng_decode_scanline are bad APIs #205

quintopia opened this issue Feb 3, 2022 · 1 comment

Comments

@quintopia
Copy link

quintopia commented Feb 3, 2022

The return value of these functions don't tell you whether the present call successfully read a row, but rather whether the next call will successfully return a row.

But for most applications, you're going to be calling these functions at the beginning of a loop, and you want to know whether the current call succeeded so you can decide whether to process the data for the row you just read. What you care about is whether the current call succesfully read a new row.

To accommodate this difference between the information you wanted and the information you got, you have to do something like the following to make sure the last row gets processed:

while (!(ret = spng_decode_row(ctx, row, width))||lastrow&&ret==SPNG_EOI) {
    lastrow = !ret;

In other words, you have to remember the result of the previous call since that was telling you what you wanted to know about the current row.

It would be better they returned 0 any time they successfully read a row, but I imagine that's not possible to fix at this point--it would break backwards compatibility. Instead, this is a request for a new pair of functions that wrap these and have only one behavioral difference: if the call to these functions returned SPNG_EOI but a new row was nonetheless successfully read by them, it returns 0 instead. Then processing an image row by row would be as simple as:

while (!(ret = spng_dec_row(ctx, row, width))) {

(The name of the new wrapper function here is just a suggestion--I made it shorter than the original since I imagine it will be used more often.)

@randy408
Copy link
Owner

randy408 commented Feb 3, 2022

Indeed, SPNG_EOI is returned for the last row, it's meant to signal that no offsets should be calculated for the next row.

This is unlikely to change at this point, I might fix it for v1.0 (and break compatibility). Another solution would be to introduce an spng_option that changes the behavior of the existing functions.

while (!(ret = spng_dec_row(ctx, row, width))) {

This is already possible:

while( !(ret = spng_get_row_info(ctx, &row_info))) {

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants