It looks like composer_scene.lua loads a JSON file, parses it and creates UI and physics objects.
I’m wondering if this was some a test unit for making scenes whilst developing/debugging the composer library and it actually is a lazy bug/bad management to include that into production?
Hmm. I personally only use Composer for its transition effects, (lazy I know), but if it’s including other frameworks just for the sake of it, then I might have to be less lazy next time.
Would be interested in any benchmarks somebody might have done with this. Do we know how much it adds to the size of an APK? Any runtime performance impacts? Memory usage?
I think I have an explanation. Years ago, we created storyboard 2.0, but because of breaking changes, we chose to give it a different name. At the same time we started creating a visual UI named Composer. This UI would create code using the new scene manager which we also called composer.* APIs. with the expectation that everyone would use the UI and to load the needed features, we probably included some of the libraries like physics for you.
While we don’t like globals specially for users who don’t understand scope and the bugs created by that and are hard to track down, including “system” libraries like physics in global space is okay. Its the way Lua does things like math and table for instance. Corona also includes network, display and audio for you all in global space.
This is a historical curiosity and a few kbytes and not a lot more.
Rob
Adding further to Rob’s history, fwiw, and my $0.02:
Once upon a time there was NO built-in scene manager. Then there was Director (a third-party scene manager). Then Corona borrowed ideas to create Storyboard (a scene manager). Then Storyboard was rebranded as Composer (a scene manager, essentially “Storyboard 2.0”).
Composer also contained new code to support the development of “Composer GUI” (which was NOT a scene manager in-and-of-itself, but rather a short-lived wysiwyg scene “designer”, built on top of the actual scene manager: Composer). Presumably to make that new code more manageable, they split out some of the scene-specific code from composer.lua into composer_scene.lua.
Composer GUI allowed you to define some basic physics properties on the display objects defined in the scene - in this way you could create simple physics-based “apps” without coding. Or, at least, that was the plan… though the wysiwyg designer never reached the stage where you could actually do anything truly “useful” with it. But that is why composer_scene requires physics.
Aside: The physics library itself leaks a global “physics” probably because it was implemented with the old-style module system via package.seeall. (we don’t know for sure, as they haven’t open-sourced that one yet, but it’s a reasonable guess given its age) But there’s no “good” reason that it should leak. (ie, it could easily be rewritten with modern module style to eliminate that leak)
Composer GUI is now abandoned and long-dead. Thus, the vast bulk of code in composer_scene.lua (including the require of the physics library) is now completely useless (and almost all of which is completely undocumented, including some that was apparently abandoned in-progress/incomplete).
IMHO, “Composer GUI” should never have been so tightly “bundled” with Composer. (IMVHO they shouldn’t have wasted their time on Composer GUI in the first place!) It should have been a separate require, (with self-contained functionality where possible/feasible, and monkey-patching scene only if/as needed, in much the same way that widget monkey-patches display), so as to leave Composer “clean”.
As it stands, Composer is now in need of a “Composer 2.0” overhaul to clear out the “junk” from the Composer GUI era. It would be similar to the Storyboard->Composer rebranding all over again, except in reverse. (instead of adding code to support Composer GUI, it’d be to remove that code)
It’s done here and when used like that with a name, luaL_register will assign the global. Would be a quick fix but who knows how much code now depends on having it.
Hah! That’s what I get for not browsing source before posting! :D Guess I assumed there was a thin lua wrapper sitting in there.
…cuz…
Given the way it’s implemented it seems odd that it wouldn’t have just “always” been a preloaded part of core (like “display”, “graphics”, et al). Then it’d be a moot point.
Agreed (re regression) - it’s too late to discuss “shouldn’t leak”, except to suggest that it “shouldn’t have leaked”.
I’m late in coming back to this discussion, but wanted to say that whether it is required or not, physics will always be built into your project. so if this discussion is predicated on the idea that “If I require it, it costs me more memory.”, then we should but that idea to bed.
‘require’ it, don’t ‘require’ it. The binary size won’t change.
well… if you never use physics (like me) then it should never be included in the build. but saying that nor should a whole heap of stuff (like themes, etc)
It is always included in all binaries. Unless something has changed, it is a core library.
In a perfect world, we would only get what we use in our binaries, but it just isn’t that simple.
Also, this is part of the price we pay for using (at least partially if not fully) pre-compiled binaries.