[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:19:44
[Download RAW message or body]

On Mittwoch, 7. August 2002 12:58, David Faure wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wednesday 07 August 2002 12:15, kudling@kde.org wrote:
> > > 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). Or do you mean, using gs to draw directly to the screen,
> > > like e.g. kghostview does? (This sounds VERY slow...)
> >
> > As a sidenote: karbon is able to import EPS for a long time now:
> > http://www.xs4all.nl/~rwlbuis/karbon/pics/epsimport.png
> >
> > Well, zooming vector graphics is faster than scaling pixmaps, and you
> > automatically know where the output should be transparent.
> > I'm not sure if it makes sense to create a tiny-karbon part, just to
> > read  and render EPS, to serve the rest of koffice.
>
> This sounds VERY good to me. It's actually the right fix. Using a vector
> graphics component to render vector graphics. Makes perfect sense.
> Much better than "pixelizing" for the current zoom level.

It is slower and memory-hungry. It is exactly what Alex do not want and what 
he complains about.

>
> However a real embedded object sounds a bit too much (e.g. if I embed
> an EPS file I don't want to edit it, I'm no artist ;), and we also want to
> save back as EPS (to preserve exact contents). Someone who wants to edit
> the graphic can always explicitely embed karbon and load from there, of
> course.

I think that Shaheed's idea about having pictures that can be changed to 
objects (and perhaps back) is much better. It has to be implemented of 
course.

>
> This leads to two solutions for EPS handling:
> * is it possible to directly convert EPS to QPicture, using something like
> karbon's EPS importer? After all Qt can render vector graphics already, all
> we need is to pass it the right data, no?

That would mean a QPicture driver for GhostScript. I have no idea how to do 
it.

> * the other possibility is a library containing karbon's core painting
> stuff, and KoPictureEPS would use it, with the EPS importer.

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
>
> iD8DBQE9UP1i72KcVAmwbhARAhdSAKCaTwezwydABfd/+YqWVFtAv0vq3gCfaByi
> IkUoSIKbJ3f8+0XnpLi2z/M=
> =YbRg
> -----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]