michael wrote: > Hi all, > > I look at the gdk-directfb implementation of the gdk-backend and I'm > very intersted on the > alpha channel. A can set the opacity of a top level window using the > directfb engine, but for > the other window I don't have a good surface to apply it. So I suppose > that it can be possible > to change the GdkWindow of an object and use and GdkWindow implemented > with the alpha channel. I try > to attach to the realize event and change the window but without > success. The operation does't fail > but I see only a gray surface. The realize use the same attribute of the > widget and change the window > type and renizialize the private data. So I suppose that wher the system > try to call the begin paint > use the new surface insted of the old one and I can reuse the > set_opacity. It can be a solution?
Only top level windows are DirectFB windows with their own "real" surface, other GdkWindows just have a sub surface within the same buffer as the top level window. At least that's how it's been for a long time... With 1.3.0 one level of sub windows was introduced. GDK-DirectFB is now able to create independently buffered child windows, maybe with a special flag from the application or automatically. With 1.5.y the full hierarchy of the screen including all sub windows up til hardware display layers will/can be managed by/through DirectFB using buffered or unbuffered rendering or composition with a very opened up engine for easy window manager and toolkit integration... ranging from purely callback based for all components over mixed shared/local code with system/user classes to fully dispatched... -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
