[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-07 12:08:33
[Download RAW message or body]

On Mittwoch, 7. August 2002 11:25, David Faure wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wednesday 07 August 2002 00:36, Nicolas Goutte wrote:
> > 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:
> > > > > So, the most time is spent in createHeuristicMask().
> > > >
> > > > It seems to make a transparent background. That is nice for
> > > > Konqueror,
>
> ... and for KWord, in many cases, I guess.

No, it does not, because it does not work. Qimage::createHeuristicMask does 
nothing to the current image. So it is a no-op, so I have removed it.

(Unfortunately, it will not be in KDE 3.0.2.)

> Especially now that it handles transparency correctly ;)
>
> I see the problem - the EPS file has the info (of where it's transparent),
> but since we use 'gs' to create a pixmap, we lose that information.
>
> > > 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."
>
> Right. However we could make it configurable (via a kimgio parameter) if
> necessary (just like the width/height option[n?]ally passed by the caller
> currently).

As it did not work, it is not a problem anymore.

>
> > 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.
>
> Ah, that's the plan? But how will it do it?
> I mean, if it does it the way kimgio does, then it'll have the same problem
> (having to "heuristically" determine the transparent part of the pixmap).

That is exactly my problem. QImageIO imposes restrictions. If we do not want 
these restrictions, we have to use something else.

> Or do you mean, using gs to draw directly to the screen, like e.g.
> kghostview does? (This sounds VERY slow...)

No, we want something fast and memory-friendly.

>
> > 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.
>
> Precision is indeed the topmost priority IMHO. But that doesn't mean we
> shouldn't try to make it as fast as possible ;)
>

Have a nice day/evening/night!

> - --
> David FAURE, david@mandrakesoft.com, faure@kde.org
> http://people.mandrakesoft.com/~david/
> Contributing to: http://www.konqueror.org/, http://www.koffice.org/
> Back from holidays
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE9UOek72KcVAmwbhARAuTdAKCCCOlbVxZg8NJiIF6r39opalLPdgCcCPDg
> lMWGHbTvdhFPyzXCGUIp/Ig=
> =cunw
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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]