GNOME Bugzilla – Bug 597169
avoid doing recomputation for overview until we re-enter it
Last modified: 2009-10-05 15:33:00 UTC
Some things we do right now on window open are probably a bit too expensive, like the entire application well is re-populated on window creation/disappearance. As a first step we could just make things like this conditional on the relevant actors being mapped; if we get e.g. favorites list changes when we're outside of the overview, just set a "stale" flag.
Created attachment 144640 [details] [review] [AppDisplay] Avoid doing expensive work when not mapped For some unknown reason we were connecting to app-added and app-removed on ShellAppMonitor in the AppDisplay class, which never made any use of the data. Simply don't connect to those signals for now. In the future we should have AppDisplay be using the AppIcon class which will more correctly handle dynamic changes. In the AppWell, avoid doing the full relayout until we're actually mapped.
Review of attachment 144640 [details] [review]: Looks OK. I'm not completely sure pending work until we enter the overview is a good idea - overview button activation has fast and it's probably better to do work when the user is *not* waiting for the overview to show up, but we need to work on that anyways - if the solution for making entering the overview fast is to get everything set up on shell startup and only do minimal updates when entering the overview, this might need rethinking.