Cairo has an issue a drawing thick line and a very specific transform matrix

[twilson90]

Sample code:

import openfl.display.Sprite;
import openfl.Lib;

class ClippingTest extends Sprite {
	public function new() {
		super();

		graphics.lineStyle(50, 0, 0.5);
		graphics.beginFill(0xff0000);
		graphics.drawCircle(150, 300, 100); // edges cut off
		graphics.endFill();

		graphics.lineStyle(1, 0x00ff00);
		graphics.drawCircle(150, 300, 125); // this draws correctly!
		scaleX = 2.7925;
		scaleY = 0.3575;
	}
}

I suspected the size of the surface / bitmapdata the graphics is drawn to was incorrectly calculated by OpenFl, but that's not it.
As you can see on the same surface I draw another circle (outlining the area of the first circle) and it is not cut off on the edges.

If I set scaleX or scaleY slightly differently (+/- 0.02) then it draws correctly.

[dimensionscape]

This issue probably belongs in OpenFL. I pushed a fix for this in dev just now: openfl/openfl@fa62df1

[twilson90]

That's not it.

I tested your fix and the circle rendered correctly, but then I altered the scale and found a new set of values to cause the same clipping:

scaleX = 2.2075;
scaleY = 0.4475;

Again, the surface being drawn to is not getting clipped by OpenFl as evidenced by the green stroke I drew ontop, which uses the same surface.
And the fix you proposed would only ever fix a single pixel of clipping.
And the issue is present only on Cairo, not HTML5 Canvas.

The issue is definitely Cairo, this version has has trouble rendering strokes with specific scaling factors for some reason.

[dimensionscape]

@twilson90

Again, the surface being drawn to is not getting clipped by OpenFl as evidenced by the green stroke I drew ontop, which uses the same surface.

Clipping is likely due to a fractional rounding error somewhere that is messing up the render bounds on on transformation.

And the fix you proposed would only ever fix a single pixel of clipping.

You confirmed yourself that the fix made the circle render correctly, which is evidence that it is obviously fixing more than a single pixel of clipping.

And the issue is present only on Cairo, not HTML5 Canvas.

Canvas can be more forgiving here.

The issue is definitely Cairo, this version has has trouble rendering strokes with specific scaling factors for some reason.

There may be a bug in Cairo itself, but as far as Lime goes, we mostly drop off into bindings. The implementation for Cairo in this respect is in OpenFL's CairoGraphics, CairoRenderer or Graphics

I will take another look with a better test.

[twilson90]

You confirmed yourself that the fix made the circle render correctly, which is evidence that it is obviously fixing more than a single pixel of clipping.

It rendered correctly merely because cairo.matrix ends up with slightly different a / d value before paint when you apply your fix to Graphics.hx.

Even with your fix applied, I still managed to cause the stroke to clip using altered scale values (stated above).

In my example if you draw ANYTHING in the Graphics with a thick stroke they all get clipped on the left and right. It's not dependent on the size of the shape.
And consistently it's clipping 1/3 of the stroke's thickness.

[dimensionscape]

In my example if you draw ANYTHING

Can you clarify this? I'm trying to build a better test for this. Its obvious there is a floating point issue or some kind or a rounding error mismatch, but it is not evident where.

[twilson90]

class ClippingTest extends Sprite {
	public function new() {
		super();
		scaleX = 0.3575;
		scaleY = 2.7925;
		graphics.lineStyle(50);
		graphics.moveTo(0, 0);
		graphics.lineTo(100 / scaleX, 0);
		graphics.lineTo(100 / scaleX, 100 / scaleY);
		graphics.lineTo(200 / scaleX, 100 / scaleY);
		rotation = 45;
		x = 100;
		y = 100;
	}
}

Cairo ❌:

Canvas ✔️:

[dimensionscape]

Again, this issue probably belongs in OpenFL, unless you can make a simple reproduction with just Lime.

[twilson90]

package;

import lime.app.Application;
import lime.graphics.RenderContext;
import lime.graphics.cairo.CairoPattern;
import lime.math.Matrix3;

class Main extends Application {
	public function new () {
		super ();
	}
	public override function render (context:RenderContext):Void {
		
		var cairo = context.cairo;
		cairo.setSourceRGB(1, 1, 1);
		cairo.paint();
		cairo.newPath();
		cairo.setSourceRGB(0.75, 1, 0);
		cairo.rectangle(0, 0, 200, 200);
		cairo.lineWidth = 50;
		cairo.lineJoin = ROUND;
		cairo.matrix = new Matrix3(2.7925,0,0,0.3575, 100, 100);
		cairo.stroke();
	}
}

Renders with cut off edges:

But with slightly altered matrix:

cairo.matrix = new Matrix3(2.81,0,0,0.3575, 100, 100);

I hope we can finally agree this is a Cairo/Lime issue :)

[dimensionscape]

I hope we can finally agree this is a Cairo/Lime issue :)

it's hard to know without isolation. In the future, try starting with a minimal reproducible example of the problem in Lime, if possible. It will save a lot of time.

Unfortunately, this looks like an issue with Cairo which means there isn't much we can do about it.

[dimensionscape]

@twilson90 The other day, I glanced at the bindings to make sure nothing strange was occurring there. I will double check. You might try updating Cairo to 1.18.4 and if that doesnt resolve things, you could create an issue here https://gitlab.freedesktop.org/cairo/cairo/-/issues

[twilson90]

Upgrading to 1.18.4 made no difference unfortunately.
I will create an issue on the cairo git.

[twilson90]

Just been trying to recreate this in C and failing, before realising I was using slightly different matrix values...
I can now confirm it's a Cairo issue
https://gitlab.freedesktop.org/cairo/cairo/-/issues?show=eyJpaWQiOiI5MjciLCJmdWxsX3BhdGgiOiJjYWlyby9jYWlybyIsImlkIjoxNDcxMjN9

[dimensionscape]

You put matrix.yy = 0.375; in the C version and 0.3575 in the haxe version...

[twilson90]

^ Yep! I immediately noticed after posting the original comment and edited it, sorry :)

[dimensionscape]

It could be possible to ignore very fine scale granularity in lime, I don't know why cairo suffers here but this is such an edge case it may never have been noticed.