Why does display come last in a function

edited November 2017 in Programming Questions

I am working through Shiffman's Learning Processing book. I notice that when using functions or classes, the function that deals with "displaying" an object always appear last in draw(). Anything that deals with movement appears first. Does anyone know a reason for that? Is it a rule or just a standard? I hope I've given enough information.


  • edited November 2017 Answer ✓

    In any animation there are two parts
    1) Updating state of the objects - calculating new positions, collision detection etc.
    2) Displaying the current state of the objects.

    They are usually done in that order because then each frame represents the current state of the animation.

  • edited November 2017 Answer ✓
    1. Position gets calculated

    2. Object gets displayed

    Now, we have the object’s variables set to some numerals and the object displayed exactly according to these numerals. Think: what will happen if it occurred the other way around:

    1. Object gets displayed (at the old values of its variables)

    2. Position gets calculated

    Now, we have an object displayed according to the old values of its variables and we have the object’s varibles set to numerals that do not correspond perfectly to the object’s actual location.

    Obviously this can cause issues.

  • Edge case: There are binary conditions at low frameRates where you might want to update variables in the draw loop after drawing -- especially for interactive sketches, where the events are processed in the gap between frame updates.

    For example, consider this sketch: it displays either red or green, once a second.

    boolean on;
    void setup() {
    void draw() {
      if (on) {
        background(0, 255, 0);
      } else {
        background(255, 0, 0);

    We decide to turn it into a simple game by adding a keyPressed check. Press a key while the sketch is green, get a hit.

    void keyPressed(){
      if(on) {
        text("YES", width/2, height/2);
      } else {
        text("NO", width/2, height/2);

    However, weirdly, everything is backwards! Pressing a key while the sketch is red (off) prints "YES", pressing a key while green (on) prints "NO." That's not what the code appears to say. What is going on?

    Moving the update of variables (on=!on;) to the bottom of draw, below the actual drawing, would be one way to solve this problem.

  • edited November 2017 Answer ✓


    the display func is the first on the stack becourse it's the last you put in a stack :) (is this english ?)

    in a minimal program it would be the exit status - return success / failure

    additional links:
    http://www.geeksforgeeks.org/memory-layout-of-c-program/ ( 4. Stack ) https://www.hackerearth.com/practice/notes/memory-layout-of-c-program/

  • Thanks to quark, randomdude, jeremydouglass, & nabr for answering the question. I apologize for taking so long to comment.

    I am not experienced enough to understand the Nov. 29 answer fully, but I'm glad to be exposed stack & heap.

    The other 3 answers combined help me to understand why the status with the new numbers should be updated before display. The "edge case" situation really makes the point poignant. BIG THANKS!

  • edited December 2017

    @DCrish -- very glad it was helpful!

    @nabr -- it makes sense, although instead of in/on I think you mean on/off or in/out?

    • the last thing you put on the stack is the first off the stack
    • the Last In is the First Out (LIFO).

    I wasn't quite sure I understood what you were saying about how LIFO relates to the order of commands in a typical draw function.

  • edited December 2017

    Yes, I want introduce the concept of stacks, you can imagine a program as kind of array:

    myarr[6] {
      do 3 times,     
      count value, 
      show count,
      if count value == 3,   
      reset count, 

    in some cases it is important where you place your instructions.
    myarr[3] = show count, // first iteration count value == initial value
    should be executed before
    myarr[5]= reset count, //
    other wise the count value would stay the same.

    Just use a debugger and see how the values are changing.
    Ask yourself what would happen, if you place a function, method, value, -whatever, to execute to a earlier point in the program flow etc.
    Processing Debugger Tutorial

Sign In or Register to comment.