I think I had better respond to some of this. The original post echoes a lot of my frustration with what happened to FLTK. It grew insanely complex but with a lot of primitive stuff baked in, and unless that stuff is removed it is never going to speed up.
Some technical points: FLTK2 uses XRender to draw antialiased images and do alpha compositing. It in fact does the best of any of the platforms at getting correct transformations (Microsoft is incredibly stupid here), but it's scaling filtering is really crap. I got in a big fight over this as my code conflicted with other code that acted as though colormap images were important (I tried to make all images simple ARGB32 pixmaps) and I think I pissed some people off and some of this is responsible for the failing of FLTK2. FLTK2 can be compiled to use Cairo. This was not finished, as pointed out, in particular it continued to use Xft to draw all the text, XRender to draw the images, and clipping was not implemented. All transforms were done by FLTK, not by Cairo. This was so it could use "linewidth==0" as an indication that it should translate all line drawing by .5 and draw 1-thick lines, which got nice crisp graphics while still getting antialiasing on the circles and diagonal lines. However it is not particularily fast. This is because it is using a *normal* X window. Cairo works but it's performance is crap. GTK and Firefox and everything else works, as stated, by allocating a local memory buffer, telling Cairo to draw there, and the *only* graphic call they do is the X "copy this buffer to the window". Cairo can draw in real X windows but sends extremely inefficient calls, often to set single pixels, over the line. And 100% of the Cairo efficiency work has been to drawing into local buffers. My recommendation is that X drawing be scrapped entirely, and you use Cairo on X11. For text you *must* use Pango, and you want to use the modern text layout on OS/X as well (and I think there is something for Windows too). This means big changes, because these things layout text in a rectangle, not from an x/y point. It is impossible to hide this so fltk's drawing interface is going to have to change to expose this. I would support HTML markup in the text (Pango does this and I think the others as well?) and scrap the '@' markup that is in fltk2. Far more important it means somebody has to find out the magic way you create an actual "fast" window for Cairo. Unfortunatly it is far to easy to get something that works but is slow. There is some weird incantation of combinations of DRI or whatever that gets you a buffer that works, and a precise call you do to copy it to the window. It may be SHM but that is ancient so I doubt it. Do not require the programmer to make "cairo window" to draw in cairo. The system should be compiled to just use cairo by default. Otherwise people will not get nice graphics, or they won't write portable programs. XDBE is useless. It should be removed completly from fltk. It is pretty obvious that even using an offscreen X window as a back buffer (which it will do without XDBE) is faster. I have no idea why those idiots at XOrg do not just make the XDBE calls do the same thing, or just make the driver say XDBE does not work. Also if Cairo draws into a local buffer you get double buffering for free. The overlay window was an attempt to remain compatible with ancient Irix code where there really was hardware overlay planes. Almost all of it should be scrapped. The only code used now is to draw the "overlay" in the front buffer of a double buffer and to erase it by copying the back buffer over. Scrap the support for multiple X visuals, which was only used to support these ancient hardware overlay planes. Images should be arrays of ARGB32 32-bit pixels. No other format should be supported. Anything that is read is directly translated to this form. Make it possible to use these for cursors and window icons (Windows is apparently more of a pain here but it can be done). I was relieved to see you mentioned shared library support for themes. This is also where I got in a big argument with the other FLTK developers. It is ugly but work should be done on loading GTK themes and calling the Windows "Appearance Manager", not on writing parsers for some fltk-specific format that no other programs use and can only set a bunch of colors. I know it is not fun but it HAS to be done this way, and it has to be done NOW, rather than pretending that after ignoring it FLTK will magically have the right underlying scheme to allow these to run. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
