2362N/A * Copyright (c) 2004, Oracle and/or its affiliates. All rights reserved. 0N/A * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 0N/A * This code is free software; you can redistribute it and/or modify it 0N/A * under the terms of the GNU General Public License version 2 only, as 2362N/A * published by the Free Software Foundation. Oracle designates this 0N/A * particular file as subject to the "Classpath" exception as provided 2362N/A * by Oracle in the LICENSE file that accompanied this code. 0N/A * This code is distributed in the hope that it will be useful, but WITHOUT 0N/A * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 0N/A * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 0N/A * version 2 for more details (a copy is included in the LICENSE file that 0N/A * accompanied this code). 0N/A * You should have received a copy of the GNU General Public License version 0N/A * 2 along with this work; if not, write to the Free Software Foundation, 0N/A * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 2362N/A * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 0N/A * The stub functions replace the bilinear and bicubic interpolation 0N/A * functions with NOP versions so that the performance of the helper 0N/A * functions that fetch the data can be more directly tested. They 0N/A * are not compiled or enabled by default. Change the following 0N/A * #undef to a #define to build the stub functions. 0N/A * When compiled, they are enabled by the environment variable TXSTUB. 0N/A * When compiled, there is also code to disable the VIS versions and 0N/A * use the C versions in this file in their place by defining the TXNOVIS 0N/A * environment variable. 0N/A/* The number of IntArgbPre samples to store in the temporary buffer. */ 0N/A/* The size of a stack allocated buffer to hold edge coordinates (see below). */ 0N/A/* Declare the software interpolation functions. */ 0N/A/* Optionally Declare the stub interpolation functions. */ 0N/A#
endif /* MAKE_STUBS */ 0N/A * Initially choose the software interpolation functions. 0N/A * These choices can be overridden by platform code that runs during the 0N/A * primitive registration phase of initialization by storing pointers to 0N/A * better functions in these pointers. 0N/A * Compiling the stubs also turns on code below that can re-install the 0N/A * software functions or stub functions on the first call to this primitive. 4301N/A * The dxydxy parameters of the inverse transform determine how 4301N/A * quickly we step through the source image. For tiny scale 4301N/A * factors (on the order of 1E-16 or so) the stepping distances 4301N/A * are huge. The image has been scaled so small that stepping 4301N/A * a single pixel in device space moves the sampling point by 4301N/A * billions (or more) pixels in the source image space. These 4301N/A * huge stepping values can overflow the whole part of the longs 4301N/A * we use for the fixed point stepping equations and so we need 4301N/A * a more robust solution. We could simply iterate over every 4301N/A * device pixel, use the inverse transform to transform it back 4301N/A * into the source image coordinate system and then test it for 4301N/A * being in range and sample pixel-by-pixel, but that is quite 4301N/A * a bit more expensive. Fortunately, if the scale factors are 4301N/A * so tiny that we overflow our long values then the number of 4301N/A * pixels we are planning to visit should be very tiny. The only 4301N/A * exception to that rule is if the scale factor along one 4301N/A * dimension is tiny (creating the huge stepping values), and 4301N/A * the scale factor along the other dimension is fairly regular 4301N/A * or an up-scale. In that case we have a lot of pixels along 4301N/A * the direction of the larger axis to sample, but few along the 4301N/A * smaller axis. Though, pessimally, with an added shear factor 4301N/A * such a linearly tiny image could have bounds that cover a large 4301N/A * number of pixels. Such odd transformations should be very 4301N/A * rare and the absolute limit on calculations would involve a 4301N/A * single reverse transform of every pixel in the output image 4301N/A * which is not fast, but it should not cause an undue stall 4301N/A * of the rendering software. 4301N/A * The specific test we will use is to calculate the inverse 4301N/A * transformed values of every corner of the destination bounds 4301N/A * (in order to be user-clip independent) and if we can 4301N/A * perform a fixed-point-long inverse transform of all of 4301N/A * those points without overflowing we will use the fast 4301N/A * fixed point algorithm. Otherwise we will use the safe 4301N/A * per-pixel transform algorithm. 4301N/A * The 4 corners are 0,0, 0,dsth, dstw,0, dstw,dsth 4301N/A * tx+dxdx*W+dxdy*H, ty+dydx*W+dydy*H 4301N/A/* We reject coordinates not less than 1<<30 so that the distance between */ 4301N/A/* any 2 of them is less than 1<<31 which would overflow into the sign */ 4301N/A/* bit of a signed long value used to represent fixed point coordinates. */ 0N/A * Fill the edge buffer with pairs of coordinates representing the maximum 0N/A * left and right pixels of the destination surface that should be processed 0N/A * on each scanline, clipped to the bounds parameter. 0N/A * The number of scanlines to calculate is implied by the bounds parameter. 0N/A * Only pixels that map back through the specified (inverse) transform to a 0N/A * source coordinate that falls within the (0, 0, sw, sh) bounds of the 0N/A * source image should be processed. 4301N/A * pEdges points to an array of jints that holds 2 + numedges*2 values where 4301N/A * numedges should match (pBounds->y2 - pBounds->y1). 4301N/A * The first two jints in pEdges should be set to y1 and y2 and every pair 4301N/A * of jints after that represent the xmin,xmax of all pixels in range of 4301N/A * the transformed blit for the corresponding scanline. 0N/A /* Increment to next scanline */ 0N/A * Class: sun_java2d_loops_TransformHelper 0N/A /* For debugging only - used to swap in alternate funcs for perf testing */ 0N/A#
endif /* MAKE_STUBS */ 0N/A /* Should never happen... */ 0N/A /* Exception was thrown by GetNativePrim */ 0N/A * Grab the appropriate pointer to the helper and interpolation 0N/A * routines and calculate the maximum number of destination pixels 0N/A * that can be processed in one intermediate buffer based on the 0N/A * size of the buffer and the number of samples needed per pixel. 4434N/A * Ideally Java should allocate an array large enough, but if 4434N/A * we ever have a miscommunication about the number of edge 4434N/A * lines, or if the Java array calculation should overflow to 4434N/A * a positive number and succeed in allocating an array that 4434N/A * is too small, we need to verify that it can still hold the 4434N/A * number of integers that we plan to store to be safe. 4434N/A /* (edgesize/2 - 1) should avoid any overflow or underflow. */ 4434N/A /* numedges variable (jlong) can be at most ((1<<32)-1) */ 4434N/A /* memsize can overflow a jint, but not a jlong */ 0N/A /* Note - process at most one scanline at a time. */ 0N/A /* All pixels from dx1 to dx2 have centers in bounds */ 0N/A /* Can process at most one buffer full at a time */ 0N/A /* Get IntArgbPre pixel data from source */ 0N/A /* Interpolate result pixels if needed */ 0N/A /* Increment to next buffer worth of input pixels */ 0N/A /* Increment to next scanline */ 4301N/A /* row spans are set to max,min until we find a pixel in range below */ 4301N/A /* Process only pixels with centers in bounds 4301N/A * Test double values to avoid overflow in conversion 4301N/A * to long values and then also test the long values 4301N/A * in case they rounded up and out of bounds during 4301N/A /* Get IntArgbPre pixel data from source */ 4301N/A /* Interpolate result pixels if needed */ 4301N/A /* Increment to next input pixel */ 4301N/A /* Increment to next scanline */ 0N/A val &= ~(
val >>
31);
/* negatives become 0 */ \
0N/A val -=
max;
/* only overflows are now positive */ \
0N/A val &= (
val >>
31);
/* positives become 0 */ \
0N/A/* For sparc, floating point multiplies are faster than integer */ 0N/A/* For x86, integer multiplies are faster than floating point */ 0N/A/* Note that on x86 Linux the choice of best algorithm varies 0N/A * depending on the compiler optimization and the processor type. 0N/A * Currently, the sun/awt x86 Linux builds are not optimized so 0N/A * all the variations produce mediocre performance. 0N/A * For now we will use the choice that works best for the Windows 0N/A * build until the (lack of) optimization issues on Linux are resolved. 0N/A *
pRes = ((a <<
24) | (r <<
16) | (g <<
8) | (b)); \
0N/A#
endif /* BICUBIC_USE_DBL_CAST */ 0N/A *
pRes = ((a <<
24) | (r <<
16) | (g <<
8) | (b)); \
0N/A#
endif /* BICUBIC_USE_DBL_LUT */ 0N/A#
endif /* BICUBIC_USE_INT_MATH */ 0N/A * The following formulas are designed to give smooth 0N/A * results when 'A' is -0.5 or -1.0. 0N/A for (i = 0; i <
256; i++) {
0N/A /* r(x) = (A + 2)|x|^3 - (A + 3)|x|^2 + 1 , 0 <= |x| < 1 */ 0N/A x = ((A+
2)*x - (A+
3))*x*x +
1;
0N/A for (; i <
384; i++) {
0N/A /* r(x) = A|x|^3 - 5A|x|^2 + 8A|x| - 4A , 1 <= |x| < 2 */ 0N/A x = ((A*x -
5*A)*x +
8*A)*x -
4*A;
0N/A for (i++; i <=
512; i++) {
0N/A#
endif /* MAKE_STUBS */