gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Slow application startup when using a theme


From: Fred Kiefer
Subject: Re: Slow application startup when using a theme
Date: Tue, 10 Jan 2012 10:12:08 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0

On 10.01.2012 09:14, Richard Frith-Macdonald wrote:

On 10 Jan 2012, at 04:54, Eric Wasylishen wrote:

I didn't like the current approach either…  I just committed a
rewrite of how theme images are handled which gets rid of theme
proxies entirely, and eliminates the code in -[GSTheme activate]
and -[GSTheme deactivate] which were setting/restoring images.

Now, when a name is set on an NSImage instance, it also subscribes
to the theme change notification. When an NSImage receives this
notification, it does the name-to-path lookup again that +[NSImage
imageNamed:] did, and reloads itself (discarding all reps) if the
path has changed.

It's a fairly major change but I tested Gorm, GSTest, SimpleAgenda,
and tried switching between the GNUstep default theme, Neos, and
Etoile's Nesedah theme while the apps were running, and all images
seemed to update properly.

The proxy approach was done so that cached references to images and
copies of images would change when the theme changes, and we wouldn't
need to go through the codebase changing all applications to either
refrain from caching/copying named images, or be theme aware and
refresh cached images when a theme changes.

Unless you've done something I missed, this rewrite will have broken
theming for any code which caches images rather than fetching them by
name each time it needs to draw ... but this may not be an issue any
more (we may have rewritten all such code to be theme aware by now)
in the GUI, and being realistic, there are probably few enough gui
apps that copy system images in existence, that we can ignore them.
But ... it would make sense to go through the GUI  code and look for
any remaining cases where the change will have broken things (or just
wait for bug reports I suppose).

Richard, you may be missing the whole point of Eric's change. When you made that proxy image change and I started criticising it we both didn't see the obvious, that Eric easily spotted: NSImage itself is already a proxy! His change now reuses the same NSImage object when the theme changes, but stores the new NSImageReps in it. There still may be some minor flaws in the code, but the basic concept sounds valid for me. The only thing about it that I cannot stand is that I did not see it myself :-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]