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

List:       kde-core-devel
Subject:    Re: kdelibs/kdeui/tests
From:       Antonio Larrosa <antlarr () arrakis ! es>
Date:       2000-11-05 23:53:03
[Download RAW message or body]

Dirk Mueller escribi=F3:
> =

> On Fre, 03 Nov 2000, Rik Hemsley wrote:
> =

> > 5 Get QPixmap to keep an 8-bit XImage alongside the other XImage
> >   when BestOptim is set.
> =

> Thats the way to go. If it doesn't work right now, then simply FIX IT i=
n the
> right place and don't try to work around it with insane amount of work.=
 Qt
> is GPL and TT is very willing to accept patches.
> =

> We need Qt 2.2.2 anyway because of the QFont size problems with high
> resolution displays. Please don't fix Qt bugs in the wrong place again =
like
> it happened with the fontsize bug. This introduces too many bugs. Now w=
e
> have to iterate over all places that has been changed again and fix the=
m
> with regart to the new, correct code.
> =


I've been talking with Rik, and we thought that maybe the best thing
is to add a "name" to QPixmap, so that you can use
QPixmap::setName("whatever");
then kiconloader can keep a cache with those names as keys.
Most application (100% ?) use icons in the same way: loadIcon(iconname)
then store the icon somewhere and then they paint it using
drawPixmap(...).
If they want to support alpha blending, that drawPixmap call would have
to be substituted for a call to KAlphaIcon::draw. That method
can take the pixmap containing the icon, extract its name, and get the
image associated with that name from the iconloader cache of QImages
which store the alpha blending.

That way, we keep using QPixmap objects, and the changes to QPixmap
are minimal (really simple).

> If the patch gets rejected, we can use KPixmap. I don't see the problem=
 why
> this should be that difficult, we inherit from QPixmap and we can acces=
s all
> necessary datafields there. KPixmap is recommended for KDE code anyway,=
 and
> now its time to use it.
> =

> If only I had a little more time I would have implemented it already. i=
ts
> really not that difficult. You just need to extend the QPixmap shared d=
ata
> handling in ::detach() (which is virtual). It shouldn't be more than 2-=
3
> hours of work.
> =

> >   Otherwise you cannot turn off the feature when it's not required,
> >   so you waste memory on the X server.
> =

> BTW, this is only a short-time hack anyway. its not worth doing ANY des=
ign
> changes. As soon as the alphablending support goes into Xserver we HAVE=
 to
> switch to it anyway (because client-side alpha blending is far too poor=
 in
> performance and XPutImage sucks heavily anyway).
> =


Yes, that's the reason why we cannot change to use QImages everywhere
or that kind of things.

> > Any other suggestions would be much appreciated.
> =

> a) Fix QPixmap that it works if it doesn't (which I doubt!).
> =


Just check kdeui/tests/kalphaicontest.cpp and tell me what's wrong :)

> b) If this is not possible, store the alpha mask as a QImage in
> KPixmap. Inherit QPixmap::detach() and handle the alpha mask copying
> there. Its really easy to do.
> =


I think it's better to just use a cache in the iconloader and assign
a name (key) to QPixmaps.

I'm nearly finished with that code, but I have classes tomorrow
morning, so I expect to finish tomorrow afternoon.

Greetings,

--
Antonio Larrosa Jimenez
KDE core developer
antlarr@arrakis.es        larrosa@kde.org
http://www.arrakis.es/~rlarrosa
KDE - The development framework of the future, today.

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