Jim, >> Will try asap, maybe tonight. I mean I will shift coordinates early in >> tosubpixx() and tosubpixy () by -0.5f. > > > Good point. It could probably still be done by the same transform, but it makes sense (and improves code independence) to keep it isolated in the Renderer class instead.
I like the pipeline uses float or double for accuracy (many affine transforms) but in the rasterizer (Renderer) deals with pixels and typically 8x8 subpixels. That's why I would like using integer maths (fixed point) in the Renderer for performance even in the curve breaking ... without sacrifying the quality. >>>> - do you know if the breakCurveAndAddLines (quad or cubic) really takes >>>> into account the supersampling scale to generate only segments needed >>>> and no more ? >>> >>> >>> I don't remember. I'd have to read the code and figure it out. >> >> >> Thanks, it seems there are some thresholds BND... but I am unable to >> find out what it is related to ? > > > I'd have to research that as well. I briefly understood them when I reviewed the code and I was able to fine-tune them once when we had failures in the FX version, but they are essentially a variant of "epsilon" but related to the adaptive subdivision algorithm so I mostly just treated them as tuning parameters - an accuracy vs. time tradeoff. It seems these values are 32 (quad) and 8 (curve) so it seems related to the scaling factor = 8. It would be great to express this dependency in the constants. > >>>> - I use fixed-point (32.32 + error) as you did but it is maybe too >>>> precise: the slope, bumpx and error could be determined from integer >>>> coordinates for starting / ending points = ceil (x1 - 0.5), ceil (y - >>>> 0.5) directly >>> >>> >>> >>> I don't understand what you are getting at here...? >> >> >> I wonder if Renderer class could use 24.8 fixed point coordinates early >> in tosubpixx() and tosubpixy () to have 1/256 precision in lineTo, >> curveTo, quadTo before addLine and curve culling to get rid of >> floating-point maths early. > > > The problem with 1/256 precision is that you accumulate 1/256 error with every step. With 8 levels of sub-pixel precision that means you can accumulate a full sampling error every 32 pixels. For nearly vertical lines where they tend to cross a whole column of samples at once that means you are off by 8 coverage values every 32 pixels (scaled by the 256/64 coverage scale to a difference of 32 in the alpha value). I understand it is not enough in the scanline processing but such 24.8 (1/256th) coordinates are more precise than 28.4 (1/8th) so it sounds possible to me to use them as inputs in addLine and curveBreak to compute the edge error, bumpx, bumperr as you did in 32.32 format for good accuracy. I want to make the curve culling as fast as possible and avoid floating-point maths in Renderer (and the slow ceil/floor calls). Of course it means its PathConsumer methods must convert float inputs to precise enough integer coords... Laurent
