On 1/29/06, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > Mike Emmel wrote: > > On 1/27/06, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > > > >>Mike Emmel wrote: > >> > >>>On 1/27/06, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>>>Mike Emmel wrote: > >>>> > >>>> > >>>>>Hi Denis it was my understanding they by default if a window is 100% > >>>>>clear i.e alpha=0 that it will not receive events by default is this > >>>>>true or false ? > >>>>>Note this is different from being shaped. > >>>> > >>>>The alpha channel only matters if DWOP_SHAPED is used. > >>>> > >>> > >>>So hidden windows with alpha 0 still get events ? > >>>It would be nice to distinguish a totally clear window an not receive > >>>events. > >>>This is different from being shaped I think. > >>>The problem is we are using alpha to mean shown or hidden. > >> > >>1. Why should one create a completely transparent window? > >>2. It would be too expensive to check for it :) > >> > > > > Thats how we attache the windows in directfb before there shown. > > Before windows are shown they should be filled with the content > that is about to be shown :) > That I have little control over bummer :(
> > There is no concept of a hide and show in directfb so we use the clear > > window > > to represent a hidden window. The problem is unless the shaped bit is set > > they > > get events. When there shown then the opacity is set to 0xFF ( should > > be the default value but that can be fixed easily ). > > > > Since its the global opacity I don't think its expensive to check for > > I like the idea of just using global opacity and not having hidden > > windows but we do need a way to turn of events when the windows are > > "hidden". > > SetOpacity(0) hides the window and prevents events being sent to it nd > Okay thats what I thought and that is what seems to be happening in window_at_pointer in default.c In any case it seems to be pretty much right and behaves as I understand it. I think there is a window ordering bug somewhere thats showing up in gtk so I need to chase it down events are going to the wrong windows. > > My view with shaped windows is that there expensive for mouse event > > handling is this not true ? > > Doesn't seem so on system that make use of this feature. > I meant when its set then you have to fallback to a pixel hit test for pointer in window instead of using the bounds. I think that can be and expensive call. Okay wrong again your just checking alpha at the pixel under x,y... I was thinking of the wrong test xy in region. Okay sorry for the fuss everything looks right I just wanted to make sure I did not make a mistake in my assumptions as I chase some of the wierd focus bugs were having. I think I can also play with the GHOST option it will help me debug. Sorry to waste your time great Directfb jedi master :) Mike > -- > Best regards, > Denis Oliver Kropp > > .------------------------------------------. > | DirectFB - Hardware accelerated graphics | > | http://www.directfb.org/ | > "------------------------------------------" > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
