[Kde-graphics-devel] Descriptions of new stuff

[Mosfet]

To give you an idea of why I like Imlib's scale, I did a quick performance 
test:

Scaling a 816x610 to 400x300 100 times:

Qt:                                                 6200ms
Imlib2 scale ported to MImage:   1274ms

And with similiar results >:) Not an official test, I use Qt timers, but it 
shows why I'm jazzed by it. The performance w/ QImage instead of MImage 
should be identical, BTW.

On Wednesday 15 December 2004 08:58 am, Lubos Lunak wrote:
> On Wednesday 15 of December 2004 15:30, Mosfet wrote:
> > ***Smoothscaling:
> > Since this is done a lot it is what everyone tries to optimize. Qt uses a
> > method based on NetPBM and is mostly integer. It's pretty good. The first
>
>  Qt's QImage::smoothScale() is pretty good only if you find it acceptable
> that something called "smoothscale" doesn't actually bother to smooth while
> scaling. Enlarge some image in basically any Qt/KDE image viewer (Gwenview
> being probably the only exception) and enjoy the Lego building blocks.
>
> > thing I did was add some MMX and 3dnow inline asm. I was able to use
> > doubleword operations to handle two pixel components at once and
> > reciprocal 3dnow multiplication for the division. It was about twice as
> > fast as the original NetPBM/Qt version.
> >
> > Then I got a look at Imlib2's scale. It replaces most of the integer
> > multiplication and division with fast bit shifts. Fairly complicated
> > code, but the normal C version runs as fast as my MMX optimized one,
> > (twice as fast as Qt/NetPBM). The MMX optimized Imlib2 scale runs twice
> > as fast as my MMX optimized one and 4x as fast as Qt. Definitely a good
> > one here.
> >
> > I've finished porting both the C and asm Imlib2 scales to QImage. It was
> > a pretty straightforward port of Imlib's scale.c. Mostly I just stuck
> > everything in a namespace, moved things around to work off of Qt BGRA
> > scanlines, and removed the unneeded border code, (as well as fixed the
> > formatting ;-). Seems to run fine. The asm routines did not need to be
> > modified at all.
>
>  I might have missed this in one of the previous mails, but is there some
> URL pointing to the sources? I'd be interested in this, because I've ported
> ImageMagick's scaling code for Gwenview
> (http://webcvs.kde.org/kdeextragear-1/gwenview/gvimageutils/scale.cpp)
> after realizing the shortcomings of Qt's smoothScale() (well, and scale()
> actually as well - interesting how one doesn't mind until the problems show
> in an image viewer). It produces very good results, and is about as fast as
> the Qt functions, but I wouldn't mind dumping it for something that's just
> as good and faster :).