From kde-core-devel Sun Feb 27 16:19:57 2000 From: Richard Moore Date: Sun, 27 Feb 2000 16:19:57 +0000 To: kde-core-devel Subject: Re: Ann: KPixmapIO X-MARC-Message: https://marc.info/?l=kde-core-devel&m=95166844418775 mosfet wrote: > > Geert Jansen wrote: > > > > mosfet wrote: > > > > > > > > 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: > > Phylosopher, Physicist, email: > > 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