On 28.01.2011, at 14:26, Edzard Egberts wrote:
> Using FLTK 1.1.3 I just found something that seems strange to me and I'm
> not sure, whether this is a bug or missing documentation:
>
> Fl_RGB_Image* myclass::Mk_Image() const
> {
> std::vector< unsigned char > Array;
> int cW, cH, cD;
> Insert_Data(Array, cw, ch, cd);
>
> return new Fl_RGB_Image(&Array[0], cW, cH, cD);
> // Crashing Images!
>
> return Fl_RGB_Image(&Array[0], cW, cH, cD).copy();
> // Okay
> }
>
> I found, that "new Fl_RGB_Image(&Array[0], cW, cH, cD)" doesn't create
> own memory for taking data of Array and as soon, as Array vanishs by
> leaving Mk_Image() the image crashes (SIGSEV) when beeing used. When
> Array is persistent, the image also stays usable. Is this desired behaviour?
Yes. The RGB data remains, but the image is converted into whatever the device
needs. This can be raw RGB, but also color mapped, or RGB16, or whatever. If
the colormap of the display changes, the device dependent bitmap must be
recalculated using the RGB data, which must still be there at that point.
> The doc only tells:
> "
> 30.84.2.1 Fl_RGB_Image::Fl_RGB_Image (const uchar ∗ bits, int W, int H,
> int D = 3, int LD =
> 0) [inline]
> The constructor creates a new image from the specified data.
> "
>
> I wondered, whether LD means "Load Data", but LD= 1 doesn't seem to have
> any effect.
LD is the line distance, the number of bytes from line start to line start.
This is used to create small images from large RGB data chunks.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
