I am sorry that there has been confusion here, I’ve been busy with the holidays, but I’m dropping in now to (hopefully!) help explain a little
Lime is a library designed to provide a consistent “blank canvas” environment on all our supported targets, so Flash Player, HTML5, Windows, macOS, Linux, iOS, Android, and others have ported Lime to consoles and set-top boxes and other systems. Lime is our cross-platform graphics, sound, input, windowing and other components, which means OpenFL can focus on being a Flash API, and not handling all these specifics. Lime also includes command-line tools, which are pretty great.
OpenFL is the Flash API. It supports rendering in OpenGL, Cairo, Canvas and even HTML5 DOM. In the browser (for instance) OpenGL is our default renderer, unless the user’s browser doesn’t give us WebGL, so we fallback to canvas. Certain features (shape.graphics or bitmapData.draw) will use software, but others (such as the display list) remain GPU accelerated.
Starling runs on Stage3D, as well as Flash APIs (such as TextField, or the event model). Starling needs a Flash API to run. It uses our Stage3D implementation, and does not really use the OpenFL display list to work.
Have you tried the Starling sample?
haxelib install starling
openfl create starling:demo
openfl test flash
There’s also a “particle-demo” included with Starling