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

List:       koffice-devel
Subject:    Re: [PATCH] Limit KoPicture's memory usage
From:       Nicolas Goutte <nicog () snafu ! de>
Date:       2002-08-06 22:36:22
[Download RAW message or body]

On Dienstag, 6. August 2002 23:35, aleXXX wrote:
> On Tuesday 06 August 2002 14:20, you wrote:
> > On Dienstag, 6. August 2002 00:33, aleXXX wrote:
> > > On Thursday 01 August 2002 14:15, you wrote:
> > > > New version in CVS! ;-)
> > > >
> > > > New features:
> > > > - EPS is now handled differently than normal images.
> > > > - EPS is not sampled at load anymore but only at first draw.
> > > > - One QImage removed for EPS, so a memory gain of an image in the
> > > > original size.
> > > >
> > > > I hope that this time the changes are visible.
> > > >
> > > > Have a nice day/evening/night!
> > >
> > > Hi,
> > >
> > > I did some measurements in kdelibs/kimgio/eps.cpp today:
> > >
> > > kpresenter: KImageIO: readImage() format = EPS
> > > ***************** EPS before popen()          1 msecs elapsed
> > > ***************** EPS before readAll()       22 msecs elapsed
> > > ***************** EPS before fwrite(ghostfd) 25 msecs elapsed
> > > ***************** EPS before pclose()       878 msecs elapsed
> > > ***************** EPS after pclose()       2911 msecs elapsed
> > > ***************** EPS: -gs
> > > -sOutputFile=/tmp/kde-alex2/kpresenterdB30Gb.tmp -q -g492x264 -dNOPAUSE
> > > -sDEVICE=png16m -c 0 0 moveto 1000 0 lineto 1000 1000 lineto 0 1000
> > > lineto 1 1 254 255 div setrgbcolor fill 0 0 0 setrgbcolor - -c showpage
> > > quit-
> > > ***************** EPS before createHeuristicMask() 3163 msecs elapsed
> > > ***************** EPS after createHeuristicMask() 11986 msecs elapsed
> > > ***************** EPS done: 11991 msecs elapsed
> > >
> > > So, the most time is spent in createHeuristicMask().
> >
> > It seems to make a transparent background. That is nice for Konqueror,
> > but
>
> As you see, on a page containing four eps files this sums up to 32 seconds
> only for createHeuristicMask(), if I have 10 pages with 4 eps files each, I
> wait 320 seconds while browsing through my presentation, i.e. more than 5
> minutes only for createHeuristicMask().

> IMO if it is not absolutely required it should be simply commented out.

This is KDE stuff, not KOffice stuff. We cannot come and say: "This feature 
annoys us, we zap it."

And in meantime, I have found out that because of this feature, you could use 
the new picture background effects (formally the clipart effects) on an EPS.

In KOffice 1.3, when KoPictureEps will take control over GhostScript we will 
be able to make it an option in KPresenter, now we cannot.

> This function call makes the app more or less unusable on my old machine
> (K6/200), and on something like a PII/400 it probably still would be no
> fun. Maybe it's ok if you are running at 1GHz, but then also probably not
> more than "acceptable".

> This year in february kpresenter was still fast, and I had no problems with
> eps-files.

The main change on kimgio for EPS files was on 2002-02-14. That patch can 
simply not be backed out now. And yes, scaling in EPS is slower, but David 
chose to be precise on EPS files, not to be fast.

The slow EPS kimgio is now in KDE 3.0.2, which will probably be the most used 
KDE version with KOffice 1.2.

>
> > I do not think we need such a thing for KOffice. It makes an argument
> > more for calling GhostScript directly from KoPictureEps in KOffice 1.3
> > (with perhaps a backport to KOffice 1.2.1.)
> >
> > (However now I have understood the reason fo the curious "1 1 254 255 div
> > setrgbcolor fill" code. It is for filling with a special color anything
> > that will not be drawn.)
> >
> > > Simply commenting it out didn't produce different images, as far as I
> > > can see. What is the parameter "showpage" good for ?
> >
> > The command "showpage" is the end of the page in PostScript.
> >
> > > Removing it reduces the time consumed by gs for one file from 2.5 sec
> > > to 2.0 sec and I didn't see a difference. Maybe it is not required when
> > > creating a png file.
> >
> > I would rather not remove it, as it seems for me like a thing that would
> > work with 90% of all images and then we would get problematic cases and
> > would not know why.
>
> Ok. Maybe it could be tested after a release.
>
> > > when scrolling a page containing four eps-images, I get debug output
> > > koffice (lib kofficecore): KoPictureEps::scaleAndCreatePixmap [497x264]
> > > slow koffice (lib kofficecore): Already cached!
> > > for each of them.
> > > Does the page have to be redrawn when it is scrolled ?
> >
> > Yes, otherwise you get all those "white stripes/lines over picture"
> > errors. But I find too that drawing many times the same image for nothing
> > is a little curious. It seems to be work for KOffice 1.3.
> >
> > > Wouldn't a bitblt() do it also ?
> > > (yes, then a pixmap (? I don't know much about images/pixmaps/...))
> > > would have to be kept in memory, but maybe only for the page which is
> > > currently displayed.
> >
> > That would be again a "speed for memory" deal. We have already many of
> > them, which makes the whole problem in KPresenter.
>
> I think having the pixmap (?) for the current page always in memory
> wouldn't hurt with regards to memory, since no matter how large the
> complete presentation is, it would always be only one (the current) page.
> But maybe we are talking about different things.

How many pixels have your "current page"? An A4 page has 822x615 points, if 
your screen is at 72 dpi (1 point==1 pixel) that makes already 494 KB.

(Not counting zooming at 500%, it would make it 25 times as big. And QT's 
QPixmap, which needs an object on the X-Server, which makes again the double.)

You could perhaps gain a little memory for pictures but how much memory would 
be lost for text, whose image is not cached now.

>
> Bye
> Alex

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]