In article <[EMAIL PROTECTED]>, Michael Sweet <[EMAIL PROTECTED]> wrote:
> > Does this mean that every widget should create an independent x drawable > > to take advantage of the compositing manager? > > Please, no. That's the old Xt model and was one of the reasons it > was so slow. 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 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). 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 probably extend draw() with another virtual parent draw(Fl_Rect), that allows a narrow region to be redrawn - much like X11 does. Not very useful and needlessly complex for normal widgets, but I guess that for a pixmap engine where you just need to draw images this can be done. 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). I like this approach best. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
