andrei_c wrote: > 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
I think that trying to use fltk's native drawing methods for a high-resolution / high-fidelity painting program is probably not useful. The fltk drawing primitives are really intended to be used for drawing the GUI and to be Fast and Light (it's in the name). 64-bit double-precision colour rendering is not generally necessary for rendering basic GUI widgets... What I would do is use fltk for the GUI elements, but build the actual rendering surface "canvas" using a dedicated rendering library, probably Cairo, but either OpenGL or AGG might work too. Using OpenGL for the drawing surface probably brings speed benefits too since it is likely to be hardware accelerated whereas Cairo or AGG may not be (though you can probably use some sort of GL/glitz type backend with Cairo of course.) Also, look at what the Cinepaint people have done - they regularly manipulate images at high bit-depths, and the "Glasgow" series is fltk based. > 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: The offscreen basically clones the bit depth of your current display - the assumption being, of course, that you are using the offscreen to composite images for mapping to the display, so it is best that they are in the same format. > 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: You may be better constructing your own "image array" in memory then using that as a canvas for your painting, rather than trying to push fl_offscreen too far... This howto might help: http://www.fltk.org/articles.php?L468 > 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. The offscreen works fine on all platforms - I use it a lot of the time. ( Though fltk-1.3 / Quartz / fl_read_image may be buggy on OSX. It is fine with QD though.) I think that comment in the code harks back to a time when fltk was unix only. That time has long since passed away... > 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. Odd - I have never had significant speed issues using fl_offscreen... > > All of this makes me wonder if I should make my own drawing functions > that draw directly on an image. Yes. I suggest you start off with Cairo or OpenGL and if they are not powerful enough for your needs, then you have to write your own. Either option works well with fltk. > 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. ??? I doubt we will ever implement higher fidelity drawing primitives. They are generally not necessary for GUI purposes, and tend to be neither Fast nor Light. For fancier drawing, anti-aliasing, etc., I tend to favour Cairo now, and have used it a fair bit with fltk. The obvious alternative is OpenGL, which can do quite a lot of what you are asking for and tends to benefit from good hardware support, so is usually fast. Someone recently posted some notes on using AGG with fltk too, and although I have not used it I hear it works well too. I wouldn't advocate setting out to write your own drawing primitives from scratch at this stage - unless you really want to of course: it is quite an interesting field to think about. We've come a long way since Bresenham's line algorithm... _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
