| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In qt_scale_image_16bit() and qt_scale_image_32bit(), when a sample
point was located on the border between two pixels in the source image,
the sample point was rounded up instead of down. If a sample point was
exactly on the bottom or right edge of the source image, the function
would therefore sample a pixel outside the image. Because of how the
target rectangle is rounded, a sample point will never be exactly on
the top or left edge of the source image, so we will not get a similar
problem there.
I extended the lance test pixmap_scaling.qps.
Task-number: 258533
Reviewed-by: Samuel
|
| |
|
|
|
|
|
|
|
|
|
| |
Add SuperH to the ever growing list of architectures which can't
correctly dereference a short* which is not 16-bit aligned. Turning this
into a white-list rather than a black list might make sense at some
point, but as QT_ARCH_I386 isn't defined on windows, the white list
looks even uglier at the moment. :-)
Task-number: 257077
Reviewed-by: TrustMe
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
|
|
| |
Don't use aliased coordinate delta for image drawing.
Related to change fde7475bcf9c10522a8170e6eb8fb9a8fadc21cd.
Task-number: 251561
Reviewed-by: Trond
|
| |
|
|
|
|
|
| |
The "optimized" version of this function was actually slower
by quite a bit, so revert it to the old "trivial" code.
Reviewed-by: Samuel
|
| |
|
|
|
|
|
|
|
|
| |
There was special code for gcc to run super-fast, but it was
buggy and didn't blend properly. Kill this code for the benefit
of the normal blend function. The performance on an Intel Quad Core 2
was not too different from the bytemul approach.
Task-number: 246009
Reviewed-by: Trond
|
| |
|
|
|
|
|
| |
The rounding was just wrong...
Task-number: 246009
Reviewed-by: Trond
|
| |
|
|
|
|
|
| |
Missing increments in the blend function's tail code.
Task-number: 247492
Reviewed-by: Paul
|
| |
|
