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

List:       koffice-devel
Subject:    Re: [PATCH] Limit KoPicture's memory usage
From:       aleXXX <alexander.neundorf () gmx ! net>
Date:       2002-08-06 21:35:58
[Download RAW message or body]

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 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.

> 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.

Bye
Alex

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