[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-26 12:12:55
[Download RAW message or body]

On Freitag, 26. Juli 2002 01:19, Pascal A. Niklaus wrote:
> At 09:47 AM 26/07/2002, you 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.)
> >
> >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.
> >
> >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.
>
> Is this an architectural problem? If the problem is that KOffice
> applications load the whole document with all embedded items when a file is
> opened, then this will also become a problem in KWord... at some point
> someone will want to write a thesis with lots of embedded graphics (e.g.
> eps or jpg files)

Yes, it is a structural problem of KWord/KPresenter 1.2. It is too late to 
change it, we can only try to limit the effects for now. (Please see my other 
email with a patch.)

And as written, I am open for ideas to change it in KOffice 1.3, if possible 
without breaking everything.

>
> Ignoring potential architectural constraints, I think having the embedded
> images for the next two slides in memory would really be sufficient, or
> maybe the next two and the previous slide. During a presentation, there
> should be plenty of time to load the next image while we're talking...
> maybe this could be done in a thread with low priority so that it does not
> interfere with animations etc? For me, this issue is KPresenter's real
> drawback. I can work around what some people think is a poor UI, but if I
> have to split a presentation into 4 files it really becomes embarrassing
> and I'll have to use WinNT/Powerpoint...

What you are writing is similar to an idea that I had last night. It is to let 
the application decide what pictures should be cached.

As for threads, I do not know. I especially do not know if QPixmap is 
thread-safe, as it uses partially X-Window. So I think that it would be again 
a gap for many problems.

>
> Pascal

Have a nice day/evening/night!

>
> _______________________________________________
> 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]