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

List:       kde-core-devel
Subject:    Re: alpha icons
From:       David Sweet <dsweet () kde ! org>
Date:       2000-10-31 3:29:27
[Download RAW message or body]

On Monday 30 October 2000 16:04 pm, Stephan Kulow wrote:
> Antonio Larrosa wrote:
> > Hi,
> >
> > As you know, I've already commited some patches to support alpha
> > icons in kicker based on Rik's cool blend method.
> >
> > Before I continue doing so for other apps, I'd like to know
> > your opinion on something. Is there any disadvantage in using
> > QImage objects instead of QPixmaps objects to store icons or images
> > in general ?
> >
> > The problem is that we're currently using Pixmaps to store icons
> > everywhere, but the alpha channel on an icon is lost as soon
> > as you use a QPixmap object (for example, when you convert
> > from QImage to QPixmap and then from QPixmap to QImage, you lose
> > the alpha information).
> >
> > The only solution is 1) use QImages everywhere in applications
> > that want to support alpha icons, or 2) as matthias suggested
> > me on IRC, have two QPixmap objects, one with the icon/pixmap
> > and another one with the alpha channel.
> >
> > Opinions ? Anyone objecting me to change each icon in a kiconview
> > to be stored as a QImage instead of a QPixmap ?
>
> Isn't that special slow? Wouldn't this result in a image to pixmap
> conversion on every paint? Or it would take twice as much memory
> which doesn't sound good as well. Whatever you do: it shouldn't use
> more resources when alpha blending is disabled

The dual-pixmap method would be much faster since the pixmaps are stored on 
the X server.  Consider, in particular, using KDE remotely.  Having to 
transmit the data (during the conversion from QImage to QPixmap) every time 
you drew an icon would make for a huge performance hit.

Dave
-- 
http://www.andamooka.org/~dsweet

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