On Thu, Mar 22, 2012 at 2:55 AM, Bill Spitzak <[email protected]> wrote: > I think I had better respond to some of this.
Thanks for chiming in! > 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. I must have missed something in the 2.0 branch of the svn repository because some of these features were not obvious to me. I implemented clipping by continuing to use the Xlib Region logic and using XClipBox to get the rectangle at the time of fl_restore_clip and use that to set the Cairo clip. I don't like the XLib logic, though, it's over complicated for rectangular clips--I think I'll end up replacing it with a stack of the the rectangle class from FLTK2 (as Cairo's native clipping mechanism, as I understand it, isn't particularly well matched to FLTK's model). > > 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. This may have changed. I'm getting good performance both with Fl_Single_Window and Fl_Double_Window... Except for circles being slow. I want to try using a cairo 'similar' surface and image surface for the backbuffer though and see if that makes any difference... It's probably wise to write a little performance test program first, though, so I can get some objective numbers. > 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. Dropping the xlib drawing was my opinion also, but I'll need to test Cairo on some slower devices first before I make up my mind. Many users of my software use it on rather underpowered netbooks (asus eeepc) which may not have accelerated graphics. By keeping the XLib rendering, I can have it as a fallback in that case (assuming Cairo is too slow on some devices). FWIW I think it's pretty stupid that Cairo doesn't just have a nice, fast "I just want to draw 1-px non-antialiased lines at integer coordinates" mode to handle cases like this. Just using cairo_set_antialias doesn't actually do much. As for Pango: I don't know about that... It depends on GLib, and if I'm going to have that crap in my process I might as well just port everything to GTK and call it a day. > 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. Even after having spent hours reading the GTK, GDK and Cairo sources, I'm still not sure how they're actually managing the window/surface and double buffering. Too many layers of abstraction and places to look. Cairo does have DRM backends, and I'm sure they're very fast (if they work), but so far I haven't found any evidence that GTK is using anything other than the xlib backend. > 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. Agreed. > 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. Yeah. It's definitely useless and slower. Turns out that nobody else even tries to use it. > 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 have no comment on these issues... > 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. Certainly not a bad idea, I'm just not entirely sure that GTK theme engines don't expect GTK/GDK/Glib to be there. If they are pure cairo calls, then it would probably be pretty easy to have a set of box drawing routines that calls out to a gtk theme engine. Otherwise, it would make a lot more sense just to port the most popular ones (98% of people use ClearLooks anyway). _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
