Le jeudi 26 juin 2008 à 15:22 -0700, Bill Spitzak a écrit : > Fltk2.0 did add a way to create a window with an arbitrary visual and > colormap, but it did not store them. Any attempt to draw would assume > you are using the default visual and colormap. But you could create a > Window object and if you overrode draw() you could draw it using your > own X code. >
In fact it's the flush() method that must be overrode, because this method creates a backbuffer with the default visual / default depth (either a window or a pixmap), and copy it to the window using a gc created with the default visual and this generate BadMatch error, and doesn't fill the window on the screen. > Making this more general is probalby ok as long as anything about X is > kept out of the public interface (ie no methods on Window). > > I'm not clear how this fixed your composite extension issues. It lets > you specify the visual, but isn't the real problem that the defualt > visual is wrong? > I doesn't really fix my problem, but this patch was made to workaround the real problem: FLTK write some value in the fourth byte of a pixel, this value is not used in 24bits visual, but in 32bits visual, it's the ALPHA channel (RGBA). So all drawing made by FLTK are more or less transparent with a 32bits visual. One would excepted it to be either fully opaque (what I want) or fully transparent (which is easy to fix), not something in the middle. It seems the fourth value is related to brightness: black color is fully transparent and white color fully opaque. Regards -- Yann Droneaud <[EMAIL PROTECTED]> +33 (0) 1 40 41 17 59 Ingénieur conseil Mandriva _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
