Sprite.graphics not displaying in html5 target on safari & chrome

Haxe
#1

I’m using graphics.lineStyle and graphics.lineTo methods just to check I’ll be able to do some drawing but it doesn’t work when I target html. neko, android, and mac all work.

Any ideas?
Thanks

EDIT: will I have to use Bitmap drawing? does bit-five offer this?

#2

Do fills work properly? Is it only lines that are not appearing?

#3

It seems the html target does not have an implicit moveTo(0,0)
Perhaps that should be added. (:

When I was calling lineTo the neko version would start from (0,0) if I didn’t moveTo another location first. The html performs as if the first lineTo was a moveTo.

#4

Would you mind sharing a little bit of sample code that illustrates the difference? How does the Flash target behave?

#5

Flash always starts drawing from (0,0) if you don’t call moveTo at the start.

Obviously this a totally pedantic request, because you don’t often start drawing from (0,0) without calling moveTo. It’s just inconsistent.

Example:

clear();
lineStyle( 1 , 1 );
beginFill( 0xffff00ff , 1.0 );
moveTo( 0 , 0 );
lineTo( 300 , 500 );
lineTo( 200 , 0 );

…would draw a triangle on all platforms.

Whereas:

clear();
lineStyle( 1 , 1 );
beginFill( 0xffff00ff , 1.0 );
lineTo( 300 , 500 );
lineTo( 200 , 0 );

…would draw a line on html5 and a triangle on other platforms because they implicitly start drawing from (0,0). Lime seems to treat that first lineTo as a moveTo on the html target.

Totally pedantic, but they’re different.

html <==> neko

Oh, CanvasRenderingContext2D behaves differently. Perhaps if it was going to be made consistent, openfl would be the place to do it. It’d just need a moveTo(0,0) in a #if html macro in Graphics.clear() and new() I imagine.

Edit:
In the openfl.display.Graphics documentation it states:

If you call lineTo() before any calls to the moveTo() method, the default position for the current drawing is (0, 0).