Lightweight API for localization of images, icons, etc.

[Chusslove Illich]

> [: David Faure :]
> My concern becomes quite different then: performance. Every call to
> KStandardDirs::findResource() (i.e. every call to locate()) is going to
> try and file the file in N language directories.... this seems like a
> rather important slow down of things. [...]

To tell the truth, I didn't think performance could be a problem here. I've
now looped one KStandardDirs::locate() call with N=3 languages in the pipe,
such that only the last has a localized resource so all 3 paths are checked,
and it delivered above 10,000 paths/sec. With no languages (i.e. en_US
only), when no paths are checked, it delivered near to 40,000 paths/sec.
Tested on a 2 GHz AthlonXP (that's vintage ~2004 average).

I don't know if the benchmark is any good, as everything is cached by the OS
already. Although I would assume that if there is a need for disk seek/read
for the original resource itself, these extra l10n path checks would drown
in the flurry. Any suggestion for a better benchmark?

> [...] I think it's dependent on the resource type; we'll never have per-
> language executables or libraries.

I'd rather not make any guesses, if not absolutely necessary. Iin fact, by
this very comment you have given me a faint idea for something... :)

> Same thing for the iconloader, I am very afraid of the performance hit
> there. [...] triple sure that this additional directory lookup is properly
> cached, the iconloader already checks a very large number of directories
> for each icon (but the icon cache helps with that).

My design intention is that the localized resource is obtained only
according to the final original resource. I've put the i18nFilePath() call
there where I did only because it was the single point from which the icon
paths emanate, and was not aware that it may be a peformance issue. But it
could also be put higher up, after all the directories have been searched,
all near-matches considered, and an original icon path finaly chosen.

Now I benchmarked with a loop of KIconLoader::iconPath() on an icon for
which I added only sr localized file (same Athlon platform):

  en_US -> ~6200 paths/sec
  sr, en_US -> ~5000 paths/sec
  fr, de, sr, en_US -> ~4100 paths/sec

Also, the localized icons themselves do get cached; when I switch languages,
to see the appropriate icons I have to delete the icon cache :) (Stale cache
by itself is part of a wider problem -- same happens for text that comes
_from desktop files, where I have to delete ksycoca cache. So a way of
invalidating/refreshing caches when appropriate is anyway pending inquiry.)

In this case, probably because I used a direct-match icon, putting
i18nFilePath call as late as possibe in KIconLoader::iconPath() gave no
improvement to the numbers above (KIconTheme:: iconPath() itself returns a
K3Icon, which is internal, so only KIconLoader can use it). But if the above
situation with performance/caching is unsatisfactory, for cases when
fallbacks are engaged, I could examine all exit points in KIconLoader and
call i18nFilePath's there instead...

> And I don't think that <full-path-to-dir-of-icon>/l10n/fr/iconname is even
> compatible with the icon spec?

The way I read the spec at
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
(thanks to Jakob for pointing me), this l10n-subdir system is not intruding
on it at all. The install paths, search and fallback mechanisms as described
in the spec remain unscathed, only once the icon path has been decided upon,
the i18nFilePath() kicks in to check if there is a localized version in its
simple-minded way.

> BTW the code in KLocale::localizedFilePath could start by checking that
> the l10n dir exists [...]

Right, and I also added shortcuts when en_US is the primary language, or
when reached in the list. (The benchmark numbers above are with these
modifications included.)

And what about the static KLocale::i18nFilePath() in the end? Use like that,
pick another name, or drop entirely?

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080115/f8799ce1/attachment.sig>