Hi Jim. We spoke about this a while ago and I started working on it. This is what I have so far: http://icedtea.classpath.org/~dlila/webrevs/RendererPerf/
My main intention was to remove some stages from the renderer (like you suggested) because what we were doing was: 1. Transform curves to lines and put the lines in a buffer. 2. Iterate through scanlines, get crossings with the lines, compute alphas, and store them into an array. 3. Compress the alpha array using RLE. 4. When asked, use the RLE encoding to generate alpha tiles. and I was hoping to be able to go directly from curves to crossings, and then generate the tiles from the crossing data. This would reduce the intermediate storage and would move around much less data. At first, I implemented this with an int[][] where each inner array represented the crossings in one pixel row, and the crossings themselves packed 3 chunks of data into one int: the x coordinate of the crossing, the orientation, the scanline within the pixel row where the crossing was located (this was a number in [0:1<<SUBPIXEL_LG_POSITIONS_Y) ). The crossings needed to be sorted, and I did this with Arrays.sort. This was fast in small tests, but for any shape with more than 4 edges per pixel row it started having huge scalability problems (for larger shapes we were spending 90+% of the time in quicksort). The version in the webrev is the fastest yet, and it uses a class similar to the ScanlineIterator for the sorting (but now it iterates through pixel rows, not scanlines). Unfortunately this means that there still are two levels of intermediate storage (edges and crossings, analogous to edges and RLE elements in the old version), but the only way I can think of how to get rid of one of them and still take use an average linear time sort is if we start outputting alphas pixelrow by pixelrow, rather than in 32x32 tiles. Anyway, it's much faster than it used to be, so we should probably push it (after I implement a cache eviction policy). Any suggestions/criticisms are always welcome. Thank you, Denis.
