On Tue, 21 Sep 2021 12:15:09 +0200 Bep Rinto <[email protected]> said:
Just FYI - I stopped working on imlib2 ... decades ago. kwo maintains it now, but a lot of this is in evas now - it loads aand can save images, can load svg's, it can do some of the reporting on formats (evas_object_image_extension_can_load_get() given a path to a file tells you if it can load it). it doesn't "load all loaders on start" but will dlopen the modules on first-need. you can limit format support by just deleting that module from disk (if its compiled as a module as opposed to inlined - common formats like png and jpeg are inlined by default). it will stat multiple times too - but that';s because loading is done in 2 phases. header then body. header lets evas figure out what dimensions the image has and if it has alpha - the body is loaded later on-demand when needed. stats are absolutely needed because of caching. you need to know if your in-memory cache for that decoded image is still valid (file on disk changed). if it's a first load you need to stat to get that data to store it alongside the cached image. you can get the version of efl/evas via api too. if you want to load your own formats you can create an empty evas image and just set its size, alpha and then fill it with pixel data yourself - there doesn't need to be some "provide your own loader" infrastructure as you can provide the data directly. evas also has the ability to use external-process loaders (a slave binary that talks to evas via stdin/out/shared memory) so you just drop a binary into the right directory and magically you can add more loaders and this then works for all apps that use evas. evas comes with a fair few pre-made ones in $PREFIX/lib/evas/utils/ e.g. for xcf (gimp format - the loader is old though and has not gained support for newer xcf variants), gstreamer (can load any frame from any video file as a result), rsvg (svg loading above), raw files, postscript, pdf and even load word/ppt/excel/etc. documents by harnessing libreoffice to do it. evas also supports animated gifs, avif (multi-frame animated too), heif, some exotic things like dds (A s3tc kind of format), jpeg2k, ico, regular gif, tiff, png, jpeg, bmp, ico, ppm/pbm/pnm, psd files (at least partly), tga, wbmp, webmp and xpm files with some custom exotic things to efl like tgv, eet. it also has the ability for some formats to only partially load some of the file - e.g. it can load part of a jpeg image due to the way jpegs work and avoid decoding most of the file to just load that region. it can also -rescale these on load by taking advantage of the fact that you can load only the lower frequency data in the DCT tiles so e.g. scale down by 2x, 4x, 8x not just for free, but for a lesser cost to load the full sized image. these come under load options in evas. evas has savers for avif, eet, jpeg, png, tgv, tiff and webp. evas also can punt loading off into slave threads (the preload request) with events when the load is done, so you can queue a bunch of loads and have them done in the background then handle the results later and not have to "stop and wait". it also has all the same caching logic imlib2 did to avoid re-loading the same image again and again when it's already decoded and in use or has been recently decoded and is still in cache. it also is a full scene graph rendering engine and can render and lay out text like imlib2 but is so far ahead it's not funny (full complex international text layout with RTL, LTR, other complex script support, color emoji support etc. etc. with complex text formatting a bit like web browsers and so on might do). if you don't have any of the opengl rendering modules and infrastructure and don't have any display system modules then it can of course not just run headless but not even have "head" dependencies like x11, wayland, drm/kms, opengl etc. etc. i stopped working on imlib2 because it was the wrong design. it loaded and saved images. it also loaded and rendered ttf fonts and text relatively simply. the problem was it was immediate-mode rendering. that was the mistake. i started evas to fix that problem - a scene graph and that is where all the improvements and work went into. you can use evas just to load images. you do need to create a canvas to so it (various efl apps do this all the time to generate thumbnails). you create a buffer canvas that "renders to memory" rather than a window. if it never has to render there is no cost in having it beyond data structures. so basically ... "use evas and you'll have pretty much all of what you want". :) adding an api to list available formats might not be too hard to add but i've never heard a good need for it. you could provide your own image loader module and drop it into the same image loader modules directory like all the others. so at least for system or user-provided loaders it'd be perfectly possible to add already - unless you specifically want an app to provide a loader via some api in which case - just set the image object data like above and do your own decode. i already covered adding in the loader binaries too. imlib2 went into maintenance mode now 2 decades ago. new development and improvements went into evas. evas is part of efl (you get all of it in one source tree but you can package it out to split out some bits you need as long as you keep the dependencies together e.g. if you just wanted evas you would need evas, eina, emile, ecore, eet, ector, eo components from efl. most of these are quite small but also provide lots of other usefulness like ecore does mainloop and core application functions, eina is data structures and similar, eet does data encode/decode and storage, ector is a vector renderer, eo an object system, emile wraps up crypto + compression/decompression stuff. > 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? > > 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. > > 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. > > 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. > > 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. > > 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. > > 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. > > Thanks for your attention. > > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
