> Most X11 implementations on commercial UNIX's and embedded systems > do not provide the Xorg composite/render extensions. > > So, while we may be able to provide an improved X11 implementation > (through Cairo I suspect), we'll still need the "bare bones" X11 > backend too...
Yes. Althought in previous post intent was for providing some friendly functions for these (e.g. Fl::visual(FL_ARGB)), there could be another approach (probably much more flexible): FLTK does not have to know about extensions at all, but play friendly if they are used. To solve this (but without using extensions in FLTK), FLTK can expose as much as possible of it's internals and the user will do the rest. I tried a few times to create ARGB window in FLTK without success; later I found a dumb reason for this: window manager would not honour client's visual; newer WM's are aware of this, and they will try to keep whatever visual and colormap client set. Also, since there is no official ARGB in FLTK, it will not "try to play" with alpha so I'm able to create window with a full background transparency. Here is a sample of the idea: http://equinox-project.org/pics/argb-window.png ...which also "solves" the problem that recently Raster (from Enlightenment) ranted about bad ARGB implementation in gtk/qt :) http://mail.gnome.org/archives/wm-spec-list/2008-January/msg00027.html The good thing is that FLTK already exposes fl_visual and fl_colormap so patching or other hacks are not needed :) > Does this mean that every widget should create an independent x drawable > to take advantage of the compositing manager? It depends; mostly you will send hints to the compositing manager and application code should not be modified at all. Some cases, like regional translucency, requires setting appropriate visual and background alpha; the compositing manager will handle the rest. > If you don't use compositing that way (which is not something I'm > recommending anyway: I don't like theming in general), then the > compositing extension is useless within the theme engine itself. And if Theming should not be complicated either; just paint image (e.g. png) with some alpha on widget and voila :) This will work for both cases: * when you want translucency with whatever-is-behind-window; CM will be involved here * when you want translucency with window background; CM not needed, FLTK already have blending > you don't perform bitmap caching, then damaging a semitransparent widget > will trigger a redraw-cascade up to the first opaque widget (in most > cases this will be the top window). Again, redrawing and/or compositing on client side is not needed. It just have to set some stuff to make life easier for the manager. > Hierarchical caching tend to waste a lot of memory; that's why the > compositing extension, by the most part, just sucks up a lot of ram > while slowing down everything. To speed up the redraw-cascade, we should Xrender compositing can be hardware accelerated (all nv cards support it). Since compositing mangers can use opengl as backend too, situation is much better with the acceleration in this field. > Carbon (and Photon, by the way), allows, for each widget, a "indipendent > drawable" option to be set. The programmer can chose were to put the > burden: memory (independent, composite-enabled widget) or cpu > (redraw-cascade up to the next composited widget). This could be solved via hints to the CM. Hints are not standardized yet, but there is already proposal to do that. -- Sanel _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
