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

List:       kde-core-devel
Subject:    Re: Ann: KPixmapIO
From:       Geert Jansen <g.t.jansen () stud ! tue ! nl>
Date:       2000-02-27 8:43:51
[Download RAW message or body]

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.

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

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