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

List:       kde-core-devel
Subject:    Re: Ann: KPixmapIO
From:       Richard Moore <rich () ipso-facto ! freeserve ! co ! uk>
Date:       2000-02-27 16:19:57
[Download RAW message or body]



mosfet wrote:
> 
> 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

You get the same problem when running large ECAD systems such as Cadence,
and visualisation tools such as AVS - the SS20 I used to work on was
configured with 512M shared memory for just this reason. I understand the
problems of SHM only too well. :-(

I totally agree with you that there needs to be both a compile time AND
a run time option. There should also be failover if the attempt to
create the SHM segment fails.

Rich.

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

-- 
     Richard Moore		rich@ipso-facto.freeserve.co.uk
http://www.robocast.com/	richard@robocast.com
http://developer.kde.org/	rich@kde.org

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