Hy everyone!
Since I am trying to make a painting program I've learned thanks to the people
from this forum that FLTK has something called offscreen drawing that allows
you to draw directly on a buffer instead of the screen.I tried to do some
examples with offscreen drawing myself and now I have some
observations/questions I want to ask.
1.First of all let me point out some things that I want for my painting program
and what FLTK has to offer in those cases:
- 24 bit RGB color drawing - check, FLTK has fl_color(uchar R, uchar G, uchar
B) which lets you select the current drawing color
- 32 bit RGBA color drawing - not sure, as far as I know fl_color() can only
have 3 parameters but maybe there's another function to set the alpha channel,
so this may be check too
- 48 bit RGB color drawing - NO, the fl_color() only supports uchar (byte)
arguments, no float or double arguments are supported through an overloaded form
- 64 bit RGBA color drawing - NO, again fl_color() seems to support only
uchar arguments
Now I want for my painting program to support 48 bit color too.Usually this
color is represented as floating point channels between 0 and 1.So they can be
either of type float or double.For my program I want both, just to give the
user the chance to work with double variables in case he really does a lot of
processing of the image and he's afraid of loosing precision.
Unfortunately it seems that FLTK doesn't offer float or double color channels,
just uchar.And because of this the drawing primitives that FLTK has to offer
can't draw with such colors either.The same functions are used in offscreen
drawing, so I can't use the built-in drawing function to draw with 48 bit
colors on an image buffer.
2.Another thing that I've observed about offscreen drawing is the fact that you
can't choose the depth of the offscreen buffer(how many channels it has,
usually 3 or 4).Check this code out:
Fl_Offscreen offscreen_image; // an image buffer
offscreen_image = fl_create_offscreen(W,H); // create the actual buffer
As you can see, fl_create_offscreen() only allows you to set the width and
heigth of the image buffer, not the depth.Is there a special function that does
that and it isn't in the documentation??Anyway, because of this I assume that
the offscreen buffers can only have 3 channels, RGB.This means that I can't
draw an image(a brush for example) with embedded transparency in it on another
image with FLTK's drawing functions.
3.Another thing that I've encountered is the fact that you can only create an
offscreen buffer in memory but you can't access the RGB values individually
from the buffer.For example:
Fl_Offscreen offscreen_image; // an image buffer
offscreen_image = fl_create_offscreen(W,H); // create the actual buffer
int i=0;
for(i=0;i<W*H*3;i++)
{
offscreen_image[i] = 255 - offscreen_image[i]; // this does not work
}
The code above doesn't work because you can't access the elements of the
offscreen buffer individually.But FLTK has a special function that tries to
solve this problem: fl_read_image().This function copies the specified
offscreen buffer to another array(buffer) of RGB values, so we can access them
individually.This solves the problem but creates another one: for the same
image you must have two buffers, so double the memory comsumption.
This is only needed if you want to access the RGB channels individually, but I
definitely need that.
4.On my computer offscreen drawing doesn't work unless I include x.H.To quote
from the x.H header documentation:
// These are internal fltk symbols that are necessary or useful for
// calling Xlib. You should include this file if (and ONLY if) you
// need to call Xlib directly. These symbols may not exist on non-X
// systems.
It seems that offscreen drawing is available or supported only on X platforms,
but I want to make my program cross platform.Is this true??On my computer it
doesn't compile without x.H if I use offscreen drawing.
5.After I include x.H it does compile but the program runs very slow.You can
see that it's slow.So that's bad.But this can be solved I guess.
All of this makes me wonder if I should make my own drawing functions that draw
directly on an image.This way I could make overloaded versions of them that
also support float arrays and even double arrays (for 48 bit color).The api
could be something like this:
void draw_line(uchar *image,int W,int H,int D,int x1,int y1,int x2,int y2)
void draw_line(float *image,int W,int H,int D,int x1,int y1,int x2,int y2)
void draw_line(double *image,int W,int H,int D,int x1,int y1,int x2,int y2)
As you can see I have full control over what kind of image I can draw on.Not to
mention that I could have some global variables or something that store even
float or double channels for color, variables that my own functions read before
drawing and then draw with those colors.
Obs:Iknow that FLTK can only display 24 RGB images via fl_draw_image() but at
least internally those images are stored as arrays of floats or doubles.So the
processing is still precise.
And not to mention that I don't have to waste time copying from an offscreen
buffer into another just so I can manipulate it element by element.And there's
no more double memory usage either.
Since most people posting on this forum are the actuall FLTK developers, you
know exactly what you have planned for future versions of FLTK, like if you're
going to make the drawing functions to draw on an array of floats or doubles
too, not just of uchars, etc.
So cosidering all my needs(especially 48 bit color) and all the problems I've
encounteres and what you FLTK developers have planned for future versions of
FLTK, what would you recommend me to do??To just use offcreen drawing as it is
implemented in a future version of FLTK( I can wait I guess) or to make my own,
like a function that draws a line or a circle, etc. ???
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
