Ugh... Qt4 porting

Lars Knoll lars at
Tue May 17 09:47:39 BST 2005

On Monday 16 May 2005 19:32, Matthias Welwarsky wrote:
> On Monday 16 May 2005 18:58, Mosfet wrote:
> [ snip ]
> > Screw this crap.
> Wasn't it Kalle Dalheimer who said the quality of a toolkit could be
> measured by the times it gets into your way while you try to be productive?

Come on. What are you talking about? We have _both_ formats. If you don't want 
premultiplied alpha, don't use it. We use it for painting on Images, as the 
speed difference is huge, and that's what 98% of the people care about.

Qt is about making the life of 95% of the developers as easy as possible, and 
the other 5% possible. Mosfets things are more the 5% case than the 95%.

> Lars, I think Mosfet has some valid points here. It's good to work on
> generalization and simplification of interfaces, but if you don't provide
> means to perform certain tasks with the same quality as before, the toolkit
> is hindering instead of helping. Losing color resolution is not good. Maybe
> you won't see a visual difference on a screen, but errors add up.

We're not hindering anyone to use the standard ARGB32 format. Guess what, 
that's even the default format we load images in. The only place we require 
the premultiplied format is when you open a painter on the QImage.

> However, as far as I understand it you're not forced to use the
> premultiplied image format, it's just faster for paint operations if you
> do? Wouldn't it then be enough to place a warning in the documentation that
> this image format should not be used if QImage is used as a data container
> for image manipulation purposes?

I think a warning is exagerrated. For most image manipulation purposes (e.g 
transformations) premultiplied alpha works as good as non premultiplied. As I 
pointed out even thoug you loose some precision (mark that you only loose it 
for low alpha values), the _visual_ appearance on the screen will be the 

The only place I can see where you probably should not use it is an image 
editor. But there it would be better to have 16bits per color channel anyway.


More information about the kde-core-devel mailing list