Search code examples
three.jsglfwcinder

Why do we update() before we draw()?

This never made sense to me. I looked at GLFW's and Three.js' examples and Cinder's implementation which actually has this comment in there:

mark all windows as ready to draw; this really only matters the first time, to ensure the first update() fires before draw()

All three libraries seem to be doing that and I don't understand why. There really is no point in updating the i.e. position of something that's never been drawn on screen or is there?

Here's what my loop looks like:

  1. Draw the (first) frame
  2. Swap buffers
  3. Update events
  4. Animate (with the input from the events), update logic, ...
  5. Start from the top

This order makes a lot more sense to me but maybe I'm missing something.

Solution

  • I think that it makes perfect sense to update objects first and then draw them.

    Imagine you animate a ball going from one side of the screen to the other and back just like a pendulum. Imagine you also want it to actually reflect real time in your computer. If you draw your scene before updating the ball's position, then where your ball will be positioned in the first frame? Unless you set it's initial position manually, it would be at zero point of your scene, which might be completely out of it's intended trajectory. If you decide to initialize it's position before start of animation, it might happen that there is a time gap causing it to be in the wrong position too.

    But if you always update it's position before drawing, it will be on the right place right from the first rendered frame.

    But to be honest - nobody will probably notice the first frame, so it is more sense of logic doing it that way rather than any practical reason. I just feel it makes more sense to prepare your scene before drawing it, not vice versa.