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

List:       koffice
Subject:    Re: kimageshop native file format and koffice filter framework
From:       David Faure <faure () kde ! org>
Date:       2000-02-22 21:38:50
[Download RAW message or body]

On Tue, Feb 22, 2000 at 08:40:10PM +0100, Werner Trobin wrote:
> Matthias Elter wrote:
> > 
> > Hi
> > 
> > 1) I'm currently implementing a native KImageShop file format using
> > KoStore and QDom. I'm basically saving image/layer/channel attributes in
> > the XML file (see kimageshop.dtd) and the actual image data in binary
> > files, all stored using KoTarStore. This gives me
> > LayerCount*ChannelCount binaries. All in all this is a easy to handle
> > and more important easy to write import filters for file format. Any
> > suggestions regarding the file format?
> 
> I don't know if KTar is able to handle that, but by default it compresses
> the binary data (=images). If I save a png image I loose some time because
> it is compressed already. Am right? Is the "performance hit" big enough to
> optimize for that case? David?

I have no idea about performance losses because of the compression.
gzopen/gzwrite is ... transparent :)

KTar supports non-compressed tar files, in fact. But it's KoStore which
uses KTarGz, always. So there is a simple solution : use KTarFile directly.

KoStore does nothing, it's just the abstraction layer that allowed
to switch between the two file formats. Well, it does one thing: the conversion
between the old naming (tar:/0/1) into the one used in tar files
(can't remember. something like part0/part1/maindoc.xml. See docu :)

If KImageShop respects this naming, it should all be fine.

(Note that gzread handles uncompressed data, so for loading there is 
no problem, even in another ko app).

> > 2) I had a deeper look into the KOffice filter framework recently. Great
> > work, Werner!
> 
> Thank you! Now we only need some filters :)
> 
> > While I like the current implementaion I'm a bit concerned
> > wether it's going to work for KImageShop. The problem is, while KWord
> > and KSpread documents are (relatively) small text files and (relatively
> > ;-) fast filtered with the current approach, importing a large TIFF
> > image into KImageShop would be quite slow because of the indirect nature
> > of the filters.
> 
> BTW: Last time I checked QDom was dog-slow. Any news on that, David?

... when used in the CSV filter it is dog slow. But I haven't
had the time to investigate more. See my comments in the xmltree file
(around the XXXXXX you put there to measure time). I think
is has something to do with the UTF 8 encoding - looks like
a bug in Qt but I'm not sure.

> > Just think of a 30MB TIFF loaded from disk, converted to
> > a temporary KIS image which is saved in a tmp dir and then opened by
> > KImageShop. What I want to say is that it might be better (faster! :-)
> > for KImageShop to import foreign file formats directly. On the other
> > hand a direct-loading filter framework for KIS would of course be
> > incompatible with the KOffice filter framework, KIS filters would have
> > to know about KIS internal data structures and link to libkiscore.
> > Opinions, suggestions?
> 
> 
> I can think of a very nasty hack to get both, but I'm not sure if that
> will work so please don't beat me for that foolish idea:
> 
> Let's assume you use the "normal" KOffice filter interface and optimize
> by:
> - allocating a huge chunk of memory (that your KIS image data fits into
>   that chunk)
> - converting the file to the KIS format
> - creating a file which contains some XML (the additional information
>   and ... yes ... the address of that chunk of memory  >:->>> )
> 
> KIS opens that temporary file and sets a pointer to that address :-P
> Now you have got the data of your image. All the additional data is
> stored in the remaining XML of the file...

This is getting very very hacky...
Gosh, it's all in the same process. Can't we design something that
gives the QDomDocument pointer directly, for those who want it ?

I understand we usually use a temp file in order to let the app
parse it the usual way - important for those apps that use koml
instead of QDom.
But for a brand new app which uses QDom natively, it should really
get hold of the document created by the filter directly.

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

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