2D vector drawing on the GPU issues

Hi, I’m experimenting with openfl trying to port my air+starling app to haxe.

I have been using starling+graphics (https://github.com/StarlingGraphics/Starling-Extension-Graphics) to draw vector graphics on the GPU with great results.

In openfl however, drawing and scaling using the Graphics API just scales the result raster, not the vector. It is a mapping application, so the results look horrible… I’m also not so sure about the render used - is Graphics API in openfl rendered in software, or on the GPU?

Could you suggest how to accomplish loss less, gpu accelerated, vector graphics with openfl? I’m really tired with Adobe and falling in love with haxe :smile:


I think it’s the reverse – Flash uses software rendering for Graphics, OpenFL by default uses hardware, but how many vertices do you need to render a smooth circle? It ends up looking blockier because of it, you can use “bitmapData.draw” to commit a shape to a software-smoothed surface, but the software rendering is not blazing fast. There is, however, ongoing work on a newer Graphics render path in “next”

I also have heard of a few people who have gotten Starling up and running over OpenFL, this is an area I expect to see improve, in a sense, having Starling is redundant (as OpenFL is already GPU-based Flash APIs, but a closer implementation than Starling is) but it could allow for porting frameworks like the one you were using

There is, however, ongoing work on a newer Graphics render path in “next”

Does this new render path leverage shaders (similar to what the AwayJS team is doing)?

Yep, absolutely :smile:

Very cool!..How long before this feature is fully implemented?

I believe the current Away3D for OpenFL builds work without an added Stage3D layer, though it’s not 100% exactly the same, we’ve got some ideas to make the layer work even more exactly the same. Starling could be ported now, or later. The main difference currently is just using a render callback function rather than using Event.ENTER_FRAME