In article <[EMAIL PROTECTED]>, matthiasm <[EMAIL PROTECTED]> wrote:
> Thanks for all your suggestions! The temptation to put a OS > compatibility layer in is high, but your arguments against it are very > good! And I could go on, but I was tired of writing ;). Just another consideration: Current themes make a lot of use of transparency. While this don't change much the layout of the theme interface, it's an issue to take into account while redrawing. Most toolkits have resorted to "compositing" (aka: hierarchical bitmap caching) to avoid the typical sluggyness of these pixmap-based engines. Transparency may also come from the root widget itself. Event handling in transparent zones? OSX does actually some kind of alpha check when delivering events. This gets really slow without readily-available alpha information. Separation of drawing and handling? Most toolkits allowed, at some point, to just "draw" a widget, without actually instantiation one. Under Carbon, this is called the AppareanceManager. QT uses this layer to draw its widgets. Some applications use them to draw the widgets in an offscreen buffer. Personally, I would think to use it to draw widgets or buttons consistently in a GL context. .... _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
