Ugh... Qt4 porting
lars at trolltech.com
Mon May 16 15:20:09 BST 2005
On Monday 16 May 2005 15:58, Mosfet wrote:
> Lars wrote:
> >> Hi Lars! You guys really need to start CCing me. I'm not on the list so
> >> am cutting and pasting responses from the mailing list archive ;-)
> >How am I supposed to know?
> I said it in this thread, I said it in the message you replied to, and you
> still didn't CC me >:)
I did (just look at the mail header), but your mail server doesn't let my mail
through, and I'm honestly not willing to go through some stupid registration
> >> Because a pixel's RGB values aren't the actual RGB values, they are
> >> averaged with the alpha value. So if your doing something like
> >> interpolating a color you'd be interpolating with the wrong color, no?
> >As long as you don't take the premulitplication into account, yes. But
> > it's
> trivial to do it right.
> >The math behind is trivial: Instead of the value being R directly, it's
> > A*R. As long as you know it's premultiplied it should be trivial to
> > adjust your code to do the same effect.
> Okay, so I was right.
> I don't even know if this deserves a response. This may be trivial to do
> this but without conversion it's a second set of a whole crapload of code
> to me and everyone else doing filters. "Doing it right" and natively using
> this format would mean two versions of most everything that accesses a
> pixel. Certainly it's a whole lot more work for me to add this than it is
> for you to keep existing functionality in QImage, no?
Yes, it needs second methods. If you have the right abstraction this should
not be terribly hard to do. Premultiplied alpha support is needed if you want
to get any decent speed when painting on QImages. The speed difference when
doing porter-duff operations (and almost all drawing is that) on a non
premultiplied and a premultiplied image is about a factor of 4-6. That's
enough for me to justify using the format.
More information about the kde-core-devel