| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3070
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 3 - Moderate, e.g. unable to compile the software |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | None |
|---|
| Summary: | fl_draw FL_Image: uchar/char |
|---|
| Version: | 1.3.2 |
|---|
| Created By: | Kennyyy |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | 1.3.2 |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
No files
Trouble Report Comments:
| |
| #1 | Kennyyy
01:13 Apr 22, 2014 |
| I have an FLTK program using an Fl_Image to draw an image. The program is working well under Linux, compiled with gcc. Now, when compiling with mingw32 (cross-compilation for Windows under Linux), the program is still compiling well, but crash (run under wine) when calling the Fl_Image::draw() method or calling a fl_draw() with the Fl_Image data passed in parameters.
Looking around, I think the problem rely (somehow, not sure exactly...) on the fact that the fl_draw or the draw method of the Fl_Image are asking for uchar (defined as unsigned char) whereas the storage of the Fl_Image is in char... I thus imagine that the problem happened when the system the program is running on doesn't have the same size for unsigned char and char...
So, the code that crash is simply something like:
FlImg=new Fl_RGB_Image((uchar *)image.data, w(), h(), 3, 0);
FlImg->redraw();
I have also tried to draw the image by myself (rewriting the draw method in a new class) using a reinterpret cast and the fl_draw function:
void draw(int xx, int yy, int ww, int hh)
{
fl_push_clip(xx, yy, ww, hh);
uchar *test=new uchar[FlImg->w()*FlImg->h()*FlImg->d()];
test=reinterpret_cast<uchar*>(const_cast<char**>(const_cast<char* const*>(FlImg->data())));
fl_draw_image((uchar*)test, xx, yy, FlImg->w(), FlImg->h(), FlImg->d(), 0);
fl_pop_clip();
delete test;
}
same effect as with the Fl_Image::draw().
Not sure if there is a bug behind that or if I'm doing something wrong... But still, if you have an explanation...
Thank you
Vincent | |
| |
| #2 | Kennyyy
01:22 Apr 22, 2014 |
| Edit: should read Fl_RGB_Image, not FL_Image | |
| |
| #3 | Kennyyy
19:50 Apr 22, 2014 |
| Sorry, problem solved. My mistake: I thought that Fl_RGB_Image was making a copy of the memory (the image) but it is not. For whatever reason (memory management), under Linux my image memory was still valid and the program was running fine whereas it was not anymore with wine.
So, keeping the memory block allocated does the job now.
And one more comment regarding my previous comment: the sizes of chars and unsigned chars can't be different but anyway there are still some parts of Fl_Image/Fl_draw where the image memory is considered to be chars whereas in some others it's considered to be uchars. Don't know if there is a reason behind that. | |
| |
| #4 | AlbrechtS
15:30 Sep 18, 2014 |
| Problem resolved, according to OP.
As for the usage of char* and unsigned char*, this is maybe for historical reasons, but doesn't matter anyway, as you noted. Thanks for the heads-up though. | |
[ Return to Bugs & Features ]
|
| |
