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

List:       koffice-devel
Subject:    Re: Kpresenter memory use
From:       Nicolas Goutte <nicog () snafu ! de>
Date:       2002-07-25 23:08:39
[Download RAW message or body]

On Donnerstag, 25. Juli 2002 23:47, aleXXX wrote:
> > From: Nicolas Goutte <nicog@snafu.de>
> >
> > If you try using KOffice 1.2 Beta 2, you will perhaps gain a little
> > memory but not much.
> >
> > The problem is that each image is stored 3 times (as a QImage, as raw
> > data and as QPixmap.) Additionally in KPresenter, you create another
> > QPixmap for each image to create the effects. (And yes, all these at the
> > loading of the file.)
> >
> > I have tried to reduce the number of duplications, but I do not see any
> > way, as the possible solutions are much slower.
>
> Well, this is really a big problem of kpresenter, otherwise it's a *very*
> nice app. As I created an approx. 30-page presentation all my 128 MB RAM
> were completely used and a considerable amount of swap space.
> It wasn't fast anymore, due to the swapping. So I am not sure whether
> creating as much as possible on demand would be really slower in the end.

If you have time, could you please put all the images into a KWord document 
and see if the same problem happens? As KWord is using KoPicture, it store 
the image three times too.

At first, when creating KoPicture, I have taken care to use less memory than 
the code that I have found at the start. (The raw data is typically 
compressed, the QImage exists only as original size and only the QPixmap has 
the big size.)

(Well, I think I see the problem: if it each direction is multiplied by 20, 
that makes 20*20 = 400 times the original size! :-((  That can already be too 
much if the original file is big, for example 1024x768 (makes 300 
Megabytes!))

Has someone an idea how we could change this without breaking kofficecore, 
KWord and KPresenter just before deep freeze? No caching at all of the drawn 
images is also not a very good solution.

>
> Maybe some kind of "cache" could help ?
> I.e. only keep up to maybe 10 pages in all three required formats in memory
> (least recently used, most often visited ones,...) and create the others on
> demand.

I had already thought of something like that for KOffice 1.3. However I have 
still no idea how to implement it.

>
> Stupid question: why are all three formats required ?

Raw data: the file as it was loaded
QImage: the image in the original size
QPixmap: the image in the drawn size.

The raw data is needed to save back the image into a file. Otherwise, EPS, 
JPEG and PNG (and WMF and SVG) files would be modified. I have a vague idea 
to use KTempFile for KOffice 1.3, but I have not thought about possible 
drawbacks yet.

> I don't know much about images/pixmaps, but I guess the different
> pixmaps/images are needed for doing different things. So, maybe it wouldn't
> hurt to much to keep only the format always in RAM which is used for the
> most often executed function ?

Then it would be the biggest one. That is also not a solution.

> The other formats which are then created on demand could be freed after a
> timeout.

No, you cannot recreate the file (especially for EPS.) That was the previous 
state (before creating KoPicture), it made people wonder why their images 
became worser and worser after each save/load cycle.

Load the file into the QImage can be slow (again especially for EPS.)

Creating the QPixmap from the Qimage is also not for free (especially for big 
zooms.)

>
> Bye
> Alex

Have a nice day/evening/night!

>
> P.S. If there were at least 28 hours per day, I would give it a try
> myself...
>
>
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@mail.kde.org
> http://mail.kde.org/mailman/listinfo/koffice-devel

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]