gunnar-ifp commented on pull request #121:
URL: https://github.com/apache/pdfbox/pull/121#issuecomment-868438983
I did some further testing, because I felt like the large scale test that
the scaling must be bigger than factor 9 x 9 is pointless and only the target
resolution is important, i.e. no matter how small the source image is, if the
target is 10000x10000, it's going to be slow. And I was right. Here some tests,
scaling up from 10, 50, 100, 500, 1000, 2000, 5000 and 10000 square to 10000:
afto = AffineTransformOp.filter(), draw = Graphics2D.drawImage(). Times in
milliseconds.
```
GRAY -> GRAY
~~~~~~~~~~~~
| Bilinear | Bicubic | Nearest
Neighbor
00010 | afto = 686, draw = 2679 | afto = 2526, draw = 8882 | afto = 227,
draw = 111
00050 | afto = 494, draw = 2679 | afto = 1658, draw = 8873 | afto = 180,
draw = 110
00100 | afto = 477, draw = 2678 | afto = 1537, draw = 8870 | afto = 181,
draw = 111
00500 | afto = 461, draw = 2678 | afto = 1451, draw = 8877 | afto = 179,
draw = 112
01000 | afto = 459, draw = 2680 | afto = 1434, draw = 8877 | afto = 181,
draw = 110
02000 | afto = 458, draw = 2677 | afto = 1424, draw = 8876 | afto = 182,
draw = 111
05000 | afto = 461, draw = 2678 | afto = 1430, draw = 8904 | afto = 182,
draw = 115
10000 | afto = 461, draw = 23 | afto = 1467, draw = 23 | afto = 182,
draw = 25
RGB -> ARGB
~~~~~~~~~~~
| Bilinear | Bicubic | Nearest
Neighbor
00010 | afto = 2133, draw = 2290 | afto = 7576, draw = 7674 | afto = 587,
draw = 147
00050 | afto = 1994, draw = 2302 | afto = 6573, draw = 7757 | afto = 530,
draw = 146
00100 | afto = 1985, draw = 2305 | afto = 6445, draw = 7680 | afto = 530,
draw = 146
00500 | afto = 1979, draw = 2417 | afto = 6327, draw = 7673 | afto = 533,
draw = 145
01000 | afto = 1979, draw = 2338 | afto = 6330, draw = 7670 | afto = 533,
draw = 147
02000 | afto = 1987, draw = 2297 | afto = 6312, draw = 7688 | afto = 538,
draw = 146
05000 | afto = 2030, draw = 2294 | afto = 6477, draw = 7691 | afto = 577,
draw = 150
10000 | afto = 2144, draw = 136 | afto = 6502, draw = 141 | afto = 720,
draw = 141
Bilinear
~~~~~~~~~~~~
| ARGB -> ARGB | GRAY -> ARGB | BINARY ->
BINARY
00010 | afto = 2130, draw = 2284 | afto = 2812, draw = 2758 | afto = 2741,
draw = 4463
00050 | afto = 1984, draw = 2281 | afto = 2573, draw = 2759 | afto = 2504,
draw = 4238
00100 | afto = 1972, draw = 2282 | afto = 2558, draw = 2758 | afto = 2349,
draw = 4235
00500 | afto = 1974, draw = 2282 | afto = 2436, draw = 2756 | afto = 2365,
draw = 4236
01000 | afto = 1975, draw = 2282 | afto = 2452, draw = 2756 | afto = 2383,
draw = 4247
02000 | afto = 1976, draw = 2282 | afto = 2527, draw = 2756 | afto = 2393,
draw = 4274
05000 | afto = 1986, draw = 2288 | afto = 3096, draw = 2760 | afto = 2582,
draw = 4507
10000 | afto = 1963, draw = 152 | afto = 5072, draw = 149 | afto = 3196,
draw = 460
```
What we can see is:
- Bicubic is ~3 times slower than bilinear.
- Using a graphics to scale up anything if the target is not not ARGB or RGB
is slow. E.g. scaling up the mask to final size.
- Graphics is always faster for nearest neighbor and if source = destination
size
With the commits of last night using AffineTransformationOp if src < dest
and interpolation is enabled, scaleImage should be a lot faster for mask
scaling and faster overall.
We can remove the scale factor test and simply test on destination pixel
area to establish thresholds for bicubic, bilinear and maybe nearest neighbor.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
