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

List:       koffice-devel
Subject:    Re: KPresenter - Memory use and JPEG import
From:       Waldo Bastian <bastian () kde ! org>
Date:       2001-06-01 18:21:36
[Download RAW message or body]

On Thursday 31 May 2001 21:51, Werner Trobin wrote:
> "Pascal A. Niklaus" wrote:
> > Hi KPresenter developers,
> >
> > When using KPresenter, I noted two issues that may be of interest to you
> >
> > developers:
> ::snip::
> >
> > 2) Although an individual presentation may be small when stored as .kpr
> > file, it can use an enormous amount of RAM. A 2MB .kpr file with 16
> > individual jpeg pictures (all compressed quite well, but all ca. 1000 x
> > 600 pixels large) caused KPresenter to start swapping... (Memory use
> > >150MB). This was really the reason why the AutoSave feature locked up my
> > computer. I had to split my presentation into 4 different parts.
> >
> > A few thoughts (without knowing about KPresenters internals): Is that
> > because KPresenter expands all the JPEG images when loading and stores
> > them in QPixMaps or similar objects?
>
> Yes, it is :}
> That's also what KIllustrator does and any other KOffice application
> I can think of at this time of the day (pre 7am ;)
>
> >If yes, would it be possible to only
> > decode/expand the images which are currently needed, and maybe the ones
> > in the next and the previous page so that they could be accessed quickly?
> > I think that would allow long presentations in a single file without
> > running into these RAM problems.
>
> Hmmm, it should be possible, but it surely is a lot of work and
> you can easily mess up that stuff. I don't even know whether we
> should solve that on application level or in the library.
> Simon, master of images, what do you think? Is there a possibility
> to put some code for that in the image handler?

Not aware of anything about koffice:

You might want to to use a ref-counting image cache and then load images for 
2 or 3 pages.

E.g. when doing a presentation use something like:

Ref images for page 1.
Show page 1.
Ref images for page 2.
Show page 2
Ref images for page 3.
Show page 3.
Unref images for page 1.
Ref images for page 4.
etc.

Images that are no longer ref'ed can be discarded at the discretion of the 
image cache. (E.g. you can keep them around till the cache exceeds a certain 
size).

Ref'ing an image will also load it if it wasn't available yet.

You probably want to distinguish between between QImages and QPixmaps as 
well. You don't want to keep to many pixmaps around since they tend to hog up 
the X-server, on the other hand you don't want to convert between the two 
much either. If you need to keep images around that you don't directly need 
(e..g they aren't ref'ed) you might want to swap them to virtual memory to 
reduce the memory requirement of kpresenter. I wrote code for that in 
kwrite/kate and I'll can probably move the virtual memory handler to kdelibs 
for that.

As you already said, I would wait with this till after 1.1 though.

Cheers,
Waldo
-- 
bastian@kde.org | SuSE Labs KDE Developer | bastian@suse.com
_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel

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