Draw line lag in rendering

Questions
1

If draw line was made into a direct function call would it become faster than message passing, or are those older messages which were made into functions still using the same system but only changed to direct function calls for convenience?

If draw data was saved into a Lua module that the render script imported and the game filled with draw requests, and if the render script had primitive draw functions, would that be faster than waiting on message passing?

If I draw a line between a point on the screen and my mouse x,y I can notice lag.

msg.post("@render:", "draw_line", { start_point = go.get_position("."), end_point = vmath.vector3(action.x, action.y, 0), color = vmath.vector4(1, 1, 1, 1) } )

Is there something about this that makes it slow? I tested on Win and Mac and both have the end point of the line drag behind the actual mouse cursor as it moves.

Maybe make some kind of input, such as current raw mouse position, directly available in the render script? Then instead of passing input data that may be stale, pass a token which tells it to use the raw mouse position data.

2

It should definitely not lag, that would be a bug with the line drawing. Message passing in general in Defold does not cause any frame lags in the common case. There are around 10-15 points during the frame where messages are handled before rendering happens. It looks roughly and conceptually like this in weird pseudo-code:

frame:
  read input
  foreach component-type in [script,collisionobject,model,sprite,gui,sound,...]:
    on_input()
  handle messages
  foreach component-type in [script,collisionobject,model,sprite,gui,sound,...]:
    update()
    handle messages
  render

One way to actually cause a frame lag would be to post messages between two scripts and the receiver would store the info from the message and handle it in its update-function, something like:

Script A: update(), which posts a message to script B
Script B: update(), “nothing” happens as the message has not been delivered yet
Script B: on_message(), receives that message and stores some state in the self variable
(rendering happens)
Script B: update(), which actually reacts to that data

If the above scenario was changed so that Script A posts the message as a response to input, the frame lag disappears:
Script A: on_input()
Script B: on_message()
Script B: update()
(rendering happens)

The frame lag would also disappear if Script B reacts immediately in the on_message function, rather than waiting for the next update(). By “reacting” I mean anything that visualises the state change, e.g. playing an animation or a sound, shader constants, enabling something, etc.

3 Likes