Re: [E-devel] 7 ideas to improve the Imlib2 image library

Hi Bep,

On 9/21/21 12:15 PM, Bep Rinto wrote:
> I would like to ask attention for the following ideas
> to improve the awesome Imlib2 software library.
> Let me first acknowledge that Imlib2 is a great piece
> of software and I thank all who contributed to it.
> 

> 1.
> All installed image loaders are loaded on startup.
> This takes time and consumes memory unconditionally.
> What if there are 100 image loaders?
> 
There aren't.

When is this a problem?
I just don't know much about imlib2 use cases except e16 and feh.
In both cases I think that the overhead in startup time and memory 
consumption from loading unnecessary imlib2 loaders is not significant.

That said, it's of course always relevant to consider speed and memory 
consumption.
If there is a simple way to improve the situation I'm all ears.
One obvious way for you is of course to only have the loaders you are 
interested in (maybe IMLIB2_LOADER_PATH is useful, see below).

> 2.
> One can't limit the possible list of image loaders.
> Say I want at most support for the TGA image format,
> but nothing else, then I would like to pass a list
> of image formats I don't want, or a list of image
> formats I want at most, but nothing else.
> 
Yeah, it would be fairly trivial to make such a feature (assuming that 
"image format" is the loader name, e.g. "foo,bar" meaning loaders foo.so 
and bar.so).

> 3.
> There is no way to obtain a list of all the image
> formats that are supported for the current execution.
> There is no way to obtain a list of the available
> image loaders, either. There is no way to query
> a single image loader for the formats it supports.
> 
Not quite sure what you want here but yeah, it would be fairly easy to 
get a list of available loaders and the associated "known" file name 
extensions (like ".jpg", ".jpeg", ".jfif" and ".jfi" for the jpeg loader).

But is this really a useful feature?

> 4.
> There is no way to obtain the current version of the
> loaded library, or to compare it to the version of the
> header file, which was included at compilation time.
> I propose to define the version in the header and
> to add a library call to obtain the library version.
> 
What is the use case here?

Why would you want to use the runtime library version?

Why not use pkg-config to do compile-time version checking?

But yeah, these features might be convenient here and there and it's 
common practice for libraries, I guess.

And still, I'd like to understand what you would use particularly the 
runtime version for.

> 5.
> When I load an image, then Imlib2 does 4 stat(2) system
> calls to load a single image. That is clearly wasteful.
> Just one call could suffice, but perhaps none is needed.
> If I give you a image file path you can just open/fopen
> it and start reading. Maybe I already have the file size,
> or the amount of bytes which Imlib2 is allowed to read
> from this section of the file.  I need to load a large
> number of small images as fast as possible and want to
> reduce the number of stat(2) system calls to the minimum.
> 
The exact number of stat calls per load depends on the loader.

Which imlib2 version are you using?
In 1.7.x the number of stat calls per load should be considerably 
reduced wrt. earlier versions.

I have been playing around with further optimizations in that area.
The number of stat calls per load won't go below 1 though.

> 6.
> The SVG format has become popular, despite its drawbacks.
> I assume it would be difficult to write a loader
> for it, but it would be nice if somehow you could
> choose to enable support for it, even if partially.
> 
Yeah, that would be nice :)

> 7.
> If my application comes with its own loaders, then
> I want to be able to communicate this to Imlib2,
> but there is no way to set a loader PATH. I assume
> that my application won't be able to augment the
> system installed set of loaders. It must remain
> a part of my application's installed file set.
> Maybe I have a preferred loader for one image format,
> which should take precedence over the system set.
> 
There is the possibility to set the IMLIB2_LOADER_PATH environment 
variable (as of v1.6.1), but it is currently only possible to specify 
one directory which then must contain all loaders you want (e.g. yours + 
soft links to the desired system ones).

If you have a better loader than imlib2 for a particular format maybe 
you should upstream it? :)


Thanks for your suggestions. Please be aware that unless someone (me?) 
finds a suggestion particularly interesting or useful, it's likely that 
nothing will happen, except, maybe, if you provide a patch.

/Kim