[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