[GEM-dev] pix_buffer_write and copy2Image()
IOhannes m zmoelnig
zmoelnig at iem.at
Fri Jan 27 09:18:54 CET 2006
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
More information about the GEM-dev
mailing list