On Tue, Sep 16, 2014 at 2:52 PM, Dominik Vogt <[email protected]> wrote:
> 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 > This would probably already make a broken maple startup usable (in this particular case).. I think we were seeing something like ~60k * 4 events when things went bad.... 15seconds would be better than 10+ minutes. > > 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. > > Probably 2 would be the easiest to implement? ... and is probably least evil as it I guess there would be little impact on other apps that can behave themselves. Maybe this style option could take a number of events it should tolerate before unsubscribing. Also, maybe another input could be a time interval, over which the events would be disregarded... so that after this time elapses, the application would start responding to the PropertyNotify again. I would be really interesting to see how gnome (metacity?) seems to deal with this - I can try to see if there is anything obvious in their code.
