[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Slow application startup when using a theme
From: |
Eric Wasylishen |
Subject: |
Re: Slow application startup when using a theme |
Date: |
Mon, 9 Jan 2012 21:54:02 -0700 |
Hi Fred,
On 2012-01-09, at 2:26 PM, Fred Kiefer wrote:
> On 09.01.2012 20:59, Eric Wasylishen wrote:
>>> That would probably works but what about changing how +imageNamed:
>>> works ?
>>>
>>> When this method is called with a image name lacking an extension
>>> (ie 'GNUstep' or 'common_arrowLeft'), it tries to find a existing
>>> file by adding any know extension and calling a NSFileManager
>>> method, and this 3 times (main bundle, theme bundle and then every
>>> Images directory in the system). With bitmaps existing only in the
>>> system directories this is extremely costly as it tries something
>>> like 500 paths before the good one. (And I know you understand all
>>> that, I'm just filling the blanks for the others who might be
>>> interested, sorry :o)
>>>
>>> Couldn't we inverse the thing and check if one of the existing file
>>> in the directories has an extension known to be an image type ? I
>>> mean : list the files in the main bundle, look for the ones with a
>>> matching name (ie 'common_arrowLeft') and then check if the
>>> extension is none. The list of file in a bundle could also be
>>> cached.
>>>
>>> Worth trying ?
>>
>> That sounds like a good idea.
>>
>> Much of the overhead when using Neos is caused by the section of
>> -[GSTheme activate] which loads all images in the theme.
>>
>> Here are some tests: startup Ink with default theme: 51k syscalls
>> startup Ink with Neos.theme: 183k syscalls startup Ink with
>> Neos.theme, with GSTheme.m lines 473 to 539 commented out: 95k
>> syscalls.
>
> I am not completely sure why this code is that way. What I remember is
> that we need to override all the already loaded images.
> But there was more to it. It could have to do with unloading an image
> and restoring the previous image state.
> I hate the way we deal with images in themes and have often stated this,
> but haven't come up with a better idea up to now.
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.
>> Fred, even if we implement image filter services support and move the
>> ImageMagick support to a service, +[NSImage imageNamed:] would still
>> do just as much work because it uses [NSImage imageFileTypes], which
>> would include the types supported by filter services.
>
> This is correct and it is what I already stated. My suggestion here was
> to rewrite imageNamed: to first check the unfiltered images and only
> later the filtered ones.
Ah, I agree that sounds like a good idea.
>> How about adding caching to NSBundle? It already caches the budle
>> info.plist, why not the directory listing of the resource directory?
>
> Here the question is what should we cache?
I'm not sure. The preliminary caching Richard just added makes a big difference
as I reported (95% reduction in system calls, when using Neos.theme and the
ImageMagick image rep is installed.)
>> Also, it might be nice if NSBundle would have a private method:
>> -(NSArray*)pathsForResource: (NSString*)name ofTypes:
>> (NSArray*)types;
>
> Yes, this is exactly the method we should be using. That way we could also
> resolve the problem of inconsistent localisation, that is the case where we
> have localisation files with different extensions and for some cases fall
> back to the non localised versions, because they get found
> first.
Ok, great. I'm not going to attempt this right now but it would be nice to do
at some point.
>> which given a name like @"common_ArrowRight" and a types array
>> (@"tiff", @"png", … ) would return an array of paths to any matching
>> resources in the bundle, and it would do so efficiently using a cache
>> of the directory contents.
>
> Sounds great, I am just wondering how Apple gets by without this method?
Not sure, perhaps they use a private method as well.
Regards,
Eric
- Re: Slow application startup when using a theme, Eric Wasylishen, 2012/01/09
- Re: Slow application startup when using a theme, Richard Frith-Macdonald, 2012/01/09
- Re: Slow application startup when using a theme, Philippe Roussel, 2012/01/09
- Re: Slow application startup when using a theme, Fred Kiefer, 2012/01/09
- Re: Slow application startup when using a theme,
Eric Wasylishen <=
- Re: Slow application startup when using a theme, Fred Kiefer, 2012/01/10
- Re: Slow application startup when using a theme, Philippe Roussel, 2012/01/10
- Re: Slow application startup when using a theme, Eric Wasylishen, 2012/01/10
- Re: Slow application startup when using a theme, Gregory Casamento, 2012/01/10
- Re: Slow application startup when using a theme, Riccardo Mottola, 2012/01/11
- Re: Slow application startup when using a theme, Riccardo Mottola, 2012/01/11
- Re: Slow application startup when using a theme, Richard Frith-Macdonald, 2012/01/12