chris clepper wrote:
I just had a crash from trying to put a 720x480 image into a 640x480 pix_buffer. I can't find any sort of check against that condition in the pix_buffer code nor in copy2Image. I think there needs to be one, so where does it make sense? I think copy2Image probably needs to do such a check before the memcpy(), but that would make it identical to refreshImage - so what purpose does each serve? Should the copy2Image be changed to refreshImage in pix_buffer and other places if the check is needed?
hi
i agree that we need a check. however i think there is one.
in my copy (which is in sync with the CVS), the copy2Image looks like: <snip> /* copy without new allocation if possible (speedup in convolve ..) */ to->xsize = xsize; to->ysize = ysize; to->csize = csize; to->format = format; to->type = type; to->reallocate(); to->upsidedown = upsidedown;
memcpy(to->data, data, xsize*ysize*csize); </snip>
now the important line is "to->reallocate();" which should enough memory (so that it at least can hold xsize*ysize*csize bytes)
as for the similiarity to refreshImage(): i think the 2 function are here because of historic reasons. refreshImage() does a little less than copy2Image() on itself - but calls copy2Image() if it doesn't know what to do. the "speed gain" of refreshImage() (i think it is meant as a faster version of copy2Image()) would come from avoiding to copy 4 fields. i think we could eventually abandon such a speed boost.... therefore i would advocate that we should get rid of refreshImage() entirely and use copy2Image() instead: i think the naming is somewhat clearer and having 1 single (working! checking!) version would reduce the confusion.
which leaves your problem unresolved: why did it crash?
mfg.asd.r IOhannes