jdf / Processing.py-Bugs

A home for all bugs and feature requests about Python Mode for the Processing Development Environment.
41 stars 8 forks source link

Color mode is not set correctly for colors in the global scope? #220

Open liavkoren opened 6 years ago

liavkoren commented 6 years ago
wrong_orange = color(24, 100, 100)

def get_orange():
    return color(24, 100, 100)

def setup():
    colorMode(HSB, 360, 100, 100)
    correct_orange = get_orange()
    background(116, 0, 13)
    size(200, 200, FX2D)
    fill(wrong_orange)
    rect(0,0,50,50)
    fill(correct_orange)
    rect(50, 0, 50, 50)

Not sure if this is actually a bug or issue, or just a subtly of the pycessing execution model that might benefit from documentation. Wrong_orange is being rendered in RGB, even though it's being used "after" the mode is set to HSB. If get_orange is called before the color mode is changed, it's also wrong.

villares commented 6 years ago

I'll try it tomorrow but looks perfectly reasonable to me. You set wrong_orange under default RGB mode. And correct_orange under HSB. Works as designed to me.

On Sun, Mar 25, 2018, 8:51 PM liavkoren notifications@github.com wrote:

wrong_orange = color(24, 100, 100) def get_orange(): return color(24, 100, 100) def setup(): colorMode(HSB, 360, 100, 100) correct_orange = get_orange() background(116, 0, 13) size(200, 200, FX2D) fill(wrong_orange) rect(0,0,50,50) fill(correct_orange) rect(50, 0, 50, 50)

Not sure if this is actually a bug or issue, or just a subtly of the pycessing execution model that might benefit from documentation. Wrong_orange is being rendered in RGB, even though it's being used "after" the mode is set to HSB. If get_orange is called before the color mode is changed, it's also wrong.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jdf/Processing.py-Bugs/issues/220, or mute the thread https://github.com/notifications/unsubscribe-auth/ADhgDBvLrFoAQdHSvLUe0YbIEBJG3Mayks5tiC2TgaJpZM4S6XUb .

liavkoren commented 6 years ago

Yep, I can see it being behavior as intended, but this was quite confusing when I first came across it, and it took me about an hour to figure out the exact issue. Maybe I'm just slow, but that's why I wonder if it might be worth noting somewhere in docs.

villares commented 6 years ago

Hi, first I would like to apologize for the terrible tone of my first answer. You are absolutely right this can be confusing and could be better documented.

I've ported and tried your code on Java mode just to be sure and it behaves the same: https://gist.github.com/villares/c10baaaf958cdd0f18d15e3dc92febf5

Then I tried to find documentation and found this https://processing.org/reference/colorMode_.html and this http://py.processing.org/reference/colorMode.html:

# If the color is defined here, it won't be 
# affected by the colorMode() in setup(). 
# Instead, just declare the variable here and 
# assign the value after the colorMode() in setup()
#bg = color(180, 50, 50) # No

def setup():
    size(100, 100)
    colorMode(HSB, 360, 100, 100)
    global bg
    bg = color(180, 50, 50)

def draw(): 
    background(bg)  
  1. I think we could add that before colorMode(HSB) is invoked colours are created by default on RGB space.

  2. It might make sense to write colour creating functions with an explicit mode setting inside (if you are using multiple modes on a sketch for some reason):

    def get_orange():
    colorMode(HSB, 360, 100, 100)
    return color(24, 100, 100)

    I hope this helps!

liavkoren commented 6 years ago

: ) 👍