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 _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev