Alle 15:43, luned� 28 luglio 2003, hai scritto: > Quoting Monge Maurizio ([EMAIL PROTECTED]): > > Hello. > > > > Working on Qt/DirectFB code suggested me a couple of things about > > DirectFB ( the port is beginning to work pretty well! give a look > > at the latest screenshot at qt-directfb.sf.net ). > > Great! > > What about moving newer screenshots to the top? ;)
I have never been a great site designer... > > > First, it could be nice if an app could find a window at (x,y), or could > > use some window-manager like policies about size, etc ... > > Some time ago someone was speaking about a window manager, isn't it? > > You may want to read the todo section on the web site. > > > Second, in DirectFB 0.9.19 there is a bug in the generic fbdev driver > > that makes unusable the multi-app core.The bug does not affect the sdl > > backend either the matrox driver. I will give a look as soon as i can... > > Are you talking about the software renderer? Yes. But sdl (that i guess to be using software rendering) is working well. > > > Third, it could be nice that a window with alpha channel could decide of > > not receiving mouse event where alpha = 0, with this shaped window can be > > implemented in Qt and receive selected events. Al that can be realized > > with the attached patch, that add the "DWOP_SHAPED" flag (to be used with > > DWOP_ALPHACHANNEL) > > I was thinking of that some time ago. Unfortunately the locking to read one > pixel for each mouse movement may be too much overhead and a faster > solution should be thought about. Anyway for each mouse movent there is "rebuild_stack" for the mouse window, that i guess to be much more exepensive, isn't it? If the surface is in system mem reading pixels is not expensive. Since reading a pixel is so fast, for every surface there could be lock flag (just a var in mem, no locking object) that if set lock will lock the surface manager. If a surface has to be moved and the flag is set the surface manager will shed_yield until the var is unset again (that should happan immediately). This solution makes expensive waiting for lock, but makes very fast lock/unlock, and this could be perfect for reading 1 pixel. > > I will apply the patch now. However, DWOP_SHAPED has to be implemented for > color keyed windows, too. You should think about using the primary > pixelformat (pixel format of the layer, i.e. no DWCAPS_ALPHACHANNEL). You > can implement shaped windows via color keying then which is way faster and > consumes less video memory. XDirectFB uses color keying for shaped windows. True. Maurizio Monge -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
