in the bowels of Solar2D

Other
#1

How can I find out more about how Solar2D works?

Is it correct to say that when a Frame starts, Solar2D and the Lua scripts will modify graphic objects which will only be really displayed during the next Frame?

Is it correct to say that there is at each frame :

  • on the one hand, a process for calculating and updating the graphic information and
  • on the other hand, a process (GPU) which is responsible for displaying everything that has been updated previously and has benn currently stored in a list of drawable objects ?

Am I correct ?

1 Like
#2

Solar2D is completely open source, so you are free to open the actual code and find all the answers you’re looking for. Of course, posting here is a good idea, because, perhaps, someone can save you some time.

#3

As @troylyndon said, the source is indeed a good way to learn the gritty details.

First things first. There are some Lua “resource” files that implement a big grab bag of features, for instance init.lua, plus some others in that same directory. Platform-specific bits have their own homes, if you have any interest in those bits.

The details you asked about are mostly in the Display and Renderer sections. I would roughly describe the former as what a Solar user sees, the latter as the under-the-hood bits.

A good first overview might be to look at the Display (captures and the Render method, in particular) and Scene (Render method) classes.

You could then look at some of the objects that show up there and drill down into their methods, e.g. those of GroupObject and other display objects (including the base class of them all). The Lua-accessible properties may be found here. Even so, it might take a while to see how it’s all wired up! :grinning_face_with_smiling_eyes:

There are some other features like adapters, found elsewhere in that Display directory, that support the various display object types, paints, and so on. These also export properties and methods.

Some renderer-level details of the frame mechanics may be found here; the underlying geometry submission is implemented further down.

You will also see, throughout this file, operations such as “bind” issued by a “command buffer”, for instance this call. This goes back to what you asked in your post:

Basically, there’s a first phase where “Lua stuff” happens: input, positioning objects, handling events, and so on.

Solar then takes a freeze-frame of the end result and “draws” this: this boils down to inserting geometry, assembling related bits (same shader, texture, blending, etc.) into batches, and issuing commands describing them.

The command buffer then grinds through this commands-and-data blob, issuing actual calls to the rendering API. (This could take place on another thread, since we actually ping-pong back and front buffers, only updating one at a time.)

And that’s a very rough overview. :smiley:

Note the GL prefix on that last command buffer link; the rendering API here is OpenGL or OpenGL ES. Various resources in the Renderer directory subclass some more generic type, CommandBuffer or Renderer for example, that expose an interface we want to flesh out.

I can confirm this was structured quite well, having gotten a Vulkan backend in working order with relatively few changes.

On that same note, I figured since the source is now open, and at this point most of these details are highly unlikely to change, we should be able to design around them, say to write low-level plugins. In this PR (and 3 follow-ups) I’ve implemented some APIs aimed at letting us hook into various stages of what I’ve described and get some fancy results.

(I don’t know how soon this could be integrated. In the meantime, I’m hoping to get some of it in order soon to try out without needing to build the engine, say just swapping out some binaries.)

Anyhow, maybe that was way more than you wanted, but I’ve been neck-deep in this stuff, the last 18 months or so especially. :slight_smile:

6 Likes
#4

Thank you for those reply.

I would love to look into the Solar2d source code, but it takes a bit of time and probably some skill I’m not sure I have :roll_eyes:
That said, it’s still tempting. One day I will.
I find that Solar2D lacks a performance indicator. I would like to know if currently my project uses 5, 10 or 50% of the performance of my smartphone!

In fact, just as there is an ‘EnterFrame’ event which marks the start of a frame, a ‘waitForNextFrane’ event indicating that all the Lua calculations have been done and that Solar2D is now waiting for the next ‘EnterFrame’ would be really nice.

I will add this project into my very long todo-wish-list :smile:

#5

How would this benefit?

#6

You can’t optimize anything If you don’t know anything about the performance of your script.

Knowing the cpu usage of your application is as important as knowing the memory usage !

#7

Based on your forum posts you are quite new to mobile dev. You optimize where needed and ignore where not. If you need a tool to tell you your code is not optimized then well…

#8

I do not understand your remark!

But finally I’m going to write a little plugin to return the value of system.nanoTime which is an accurate enough timer on android to allow me to measure the efficiency of my functions.

Indeed LUA is brand new to me!

#9

What I mean is as you learn more you will also learn what is performant and what is not. A simple example is don’t move 100 objects manually. Place them in a group and move the group instead. The framework will always be faster than Lua code.

#10

Have you read this guide?

https://docs.coronalabs.com/guide/basics/optimization/index.html

#11

Sure I’ve readed it :slight_smile:

#12

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.