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

List:       kde-core-devel
Subject:    Re: Ann: KPixmapIO
From:       mosfet <mosfet () mandrakesoft ! com>
Date:       2000-02-27 14:07:10
[Download RAW message or body]

Geert Jansen wrote:
> 
> mosfet wrote:
> 
> > <IMHO>
> > I already said this several times but here I go again...
> >
> > MIT-SHM is great for single multimedia windows, as long as you have code
> > that will also operate without it. It should not be used for several
> > potentially large pixmaps. It's a limited resource on many systems (the
> > maximum for all apps is defined as a kernel parameter), many apps such
> > as databases also need it, and on some Unix'es very little is allowed by
> > default ie: ~1/2 meg. After a pixmaps you run out of space. Thus it's
> > not really usable for themes and should not go in transparent konsole,
> > but would be potentially cool for a multimedia class. You could simply
> > allocate it until if fails, but then you end up having to do a recently
> > used scheme to optimize and code to handle when it fails.
> 
> Hiya mosfet.
> 
> I know your feelings about MIT-SHM and I think you're right. But, you
> didn't look at the code, did you? :-)
> This is not yet-another fastpixmap. It's about pixmap-image conversions
> only.  When transferring a lot of images, you'd use:
> 
> KPixmapIO io;
> for (i=list.begin(); i != list.end(); i++) {
>     io.loadImage(*i);
>     pm = io.pixmap()
> }
> 
> There's only one shared memory segment used here, and as soon as the
> transfer is complete, it's not used anymore.
> 
> It can be used beneficially whenever there are large images to be
> transferred. If MIT-SHM is available, the conversion will be fast,
> otherwise, they will be normal speed.
> The shared memory is not used anymore after the transfer and will be
> deleted. You won't run out of SHM this way.
> And in the case where you cannot even allocate one segment, you have the
> old situation, so you loose nothing.
> 
> So what about using this in KPixmapEffect, for conversions bigger than a
> yet to be determined threshold?
> 
> > As a ex-sysadmin if KDE used MIT-SHM for pixmaps I would never install
> > it on any production machine that also runs apps using Unix shared
> > memory, like Oracle.
> 
> Ok, if there are several apps that are transferring pixmaps with KPixmapIO
> at the same time, you eat up a number of shared memory segments. We could
> provide a --disable-mit-shm option for this.
> 
> FYI: on Linux, the limits are: 128 segments of 32 Mb each.
> 

And on some versions of SUN it's a total of half of a meg by default >:)

Reading the above, I don't have a problem with the I/O implementation
you mentioned, that does sound pretty cool. I had a problem with using a
bunch of them for something like the theme pixmaps. If your only using
it to speed up the conversions between QImage and QPixmap on load, and
then getting rid of it that should cool.

Instead of just a configure option tho, I would also do a KConfig
parameter as well so it can be shut off after compile by sysadmins.

The reason why I jump on using shared memory so much is that when I was
admin'ing database servers I constantly had to deal with DBA's always
pushing for more shared memory. To many people it's the solution to all
performance problems ;-) If they found out I was using it for something
like themes they would have my head (although if you are using themes on
a production server you should be thwacked anyways ;-) Either way, a lot
of people view their shared memory blocks as something sacred :P

> Greetings,
> --
>     Geert Jansen                       email: <g.t.jansen at stud.tue.nl>
>     Phylosopher, Physicist,                    email: <jansen at kde.org>
>     KDE enthusiast                                 PGP key ID: 0xD2B5E7CE

-- 
Daniel M. Duley - Unix developer & sys admin.
http://www.mosfet.org - The place for KDE development news.
mosfet@mandrakesoft.com
mosfet@kde.org

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