[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KImgio (Was: App start is too slow)
From:       Waldo Bastian <bastian () kde ! org>
Date:       2000-04-29 0:06:37
[Download RAW message or body]

Ok.

I have done the following (not commited yet).

* I moved kimgio.[cpp|h] to kio.
* kimgio loads additional libs only when needed
* *.kimgio files define all available image types and whether additional libs
  need to be loaded.
* The *.kimgio files are stored in ksycoca to access them faster. (Startup is 
now a wopping 37ms faster.)

My questions: 
* What would be a good place to store the *.kimgio files? I currently store
them in $KDEDIR/lib, but I don't think that is the best place for them.

* kdelibs/kimgio seems not very well maintained. It looks like only "EPS", 
"KRL", "TIFF" and "XView" make sense. "EPS" didn't work for me. What is "KRL"?

* JPG is part of Qt right? So kimg_jpeg.la is obsolete, correct?

* With my change $LIB_KIMGIO would be obsolete. kdelibs/kimgio would contain 
only plugins for "strange" image format (eps, krl, tiff, xview and whatever 
the future brings)

Cheers,
Waldo

On Wed, 26 Apr 2000, Waldo Bastian wrote:
> > > Isn't it possible to register dummy handlers based on information in
> > > the .desktop file and to load the actual lib when you are about to
> > > load/save a certain image type?
> >
> > I'm afraid not that easy, but it could be possible.
>
> I did some tests but having/not having kimgio plugins hardly affects
> start-up performance (It differs about 40ms) . So I don't think we need
> this for start-up performance.
>
> I do think it would be "the right thing" to only load these modules when we
> really need them though. That would mean that we need to read some .desktop
> files instead to find out which image formats are supported. This should
> not take more time than actually loading the libs themselves, because then
> we would only make matters worse.
>
> Information to be stored in the .desktop files is:
> 1) Type (aka. format, arg 1 of QImageIO::defineIOHandler)
> 2) Header (arg 2. of defineIOHandler)
> 3) flags (arg 3. of defineIOHandler)
> 4) pattern-lines (see KImageIO::pattern())
> 5) Read supported
> 6) Write supported
> 7) List of file suffices (Maybe in combination with 4)
> 8) Mimetype
> 9) Library to load for this image format
>
> Note that the desktop defines an image format and that a library can be
> shared among several image formats. (E.g. the imagemagick IO lib defines 9
> types.)
>
> Cheers,
> Waldo

[prev in list] [next in list] [prev in thread] [next in thread]