Jim, >> - improve coordinate rounding ie ceil(x - 0.5) or better ? >> Maybe ceil/floor(float) intrinsics could help but let's discuss that in >> the core-libs mailing list... >> I have found another trick about float rounding: >> http://stereopsis.com/sree/fpu2006.html >> Or you may have other ideas as you did in your JavaFX renderer ? > > > We might want to consider fixed point in the inner loops and then we can bypass the issue entirely. It would also mean that we'd only need one kind of array for storing segments. The main advantage to using FP is if you have a lot of FP math and a lot of integer stuff, then the FP math can sometimes hide in the gaps between the integer and logic instructions since they can execute in parallel. But, if you run across an expensive FP operation then fixed point might be faster anyway.
There are 2 issues: - dasher, stroker, transformer and curve culling provide coordinates as float values that finally call Renderer.addLine (floats) which converts it to the subpixel grid => rounding to subpixel centers is necessary => fast floor / ceil functions are useful and also in endRendering() to adjust the shape area to subpixel clip bounds. It is then possible to convert coordinates to fixed point 24.8 format => edges as integer values (like agg). 2. Scanline processing Currently crossings as integer subpixel x coord are incrementally computed from previous crossing + slope (float) and casted to integer => rounding issue at x position. In this hot loop, using fixed point maths could help (= DDA) but its error should be properly propagated. It may be faster if dda is properly and efficiently implemented. Do you know some good books or readings on this topic ? Laurent
