On Mon, Sep 15, 2014 at 11:32:18PM +0100, Dominik Vogt wrote: > On Mon, Sep 15, 2014 at 05:20:59PM -0400, Peter G wrote: > > > Can you please try out the latest cvs code wogether with the debug > > > patch attached to this message? I need to see some stretch of the > > > log again (only the part with the ..._NAME atoms, the rest is > > > irrelevant). > > > > Thanks for the update and the patch. > > Unfortunately it's not working form me. A clean checkout of the cvs, > > branch-2_6, either with the patch or no patch applied. As fvwm loads, one > > cpu spins up and stays at 100%. > > Hmpf, I *had* tested that fvwm worked. Maybe an old executable > ran. But now ...
If I disable the debug output, fvwm can throw away 400000 alternating PropertyNotify events for WM_NAME and WM_ICON_NAME in about 30 seconds at about 35% cpu (on my machine, of course). Not very good but better than before. :-/ Even if it could do so faster, we'll hit a wall because the events are sent to the X server and then forwarded to fvwm. I see several possible ways to improve this: 1) Try to erase events even faster. Maybe the predicate procedure that browses through the events could change their destination window to some fvwm internal window so when the events are read they can be recognized and dropped immediately. This would be an evil hack and may not work. 2) Add a style option to unsubscribe from PropertyNotify events after a couple have been read (to allow the application to set some hints at startup). 3) Unsubscribe PropertyNotify events when fvwm detects that the application is going crazy. May be very difficult to detect automatically, and when this finally kicks in it may be too late. There's no way to get rid of unwanted events that are already on the input queue quickly. Suggestions? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
