Quoting Maurizio Monge ([EMAIL PROTECTED]): > Hello, it is time of my weekly mail with a patch and a couple of > insane ideas :-) > > This patch is an optimization in window repaints/moves/resizes that discards > the repaint of opaque windows/regions that are above the window. > It is for instance useful when you have an opaque window on the top and under > it a dfbterm that is giving ton of output.
This is great. I was thinking about something like that many times but never found the time to implement it. I will try the patch now and commit it to CVS. Maybe we'll find a nicer version of the complex if statement some day. > So you can also resize the window flicker-free (using size grips in gtk/qt). > I think that resizing through the wmhack is not flicker-free because of > syncronization problems, i.e. during resize: > -the app draws to the surface. > -the wm(i think the input thread) resizes the surface. > -the app flips the surface. Indeed. The wmhack resizing is done by the master (in the input thread). This should be moved to the upcoming window manager core module doing builtin resizing locally in the app. It will still run in a different thread than the paint/flip, but there's a greater chance of builtin synchronization. > I tried to implement messages through unix signals, ie no messaging thread and > the app is SIGIO-killed when a message is avalable (adding > "kill_proc (fusionee->pid, SIGIO, 1);" at the end of fusionee_send_message in > fusionee.c). > It does not work for the following king of problem: > -the app calls a malloc > -the malloc sets a lock > -the app receives a SIGIO > -the SIGIO handler calls another malloc > -the malloc waits the lock forever. > Any idea? No ;( -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
