Scratch-vm: Add full transparency support for pen

[TheBrokenRail]

For block example see the Blockly RGB block.

Currently, to make a color using RGBA requires you to use some weird numbers, that new Scratchers probably will not understand, adding a block that allows you to easily make a RGBA color will make making RGBA colors easier and less confusing for new Scratchers.

Blockly Example

[thisandagain]

@cwillisf @ntlrsk @carljbowman Any thoughts on this? I like the idea, but I'm wondering where we would put it in the block menu (e.g. "pen", "operators", etc.) and how we would communicate the "alpha" / "transparency" argument.

(color with red () green () blue () alpha ()) feels too technical
(color with red () green () blue () transparency ()) is too long

[thisandagain]

I also wonder if RGB is the right color model. In past discussions I've argued for HSV/HSB:
https://en.wikipedia.org/wiki/Comparison_of_color_models_in_computer_graphics

In either case, I wonder if the nascent "color picker" field drop-down may be the better solution to this rather than providing multiple numeric inputs (albeit less powerful).

[carljbowman]

@thisandagain - https://github.com/LLK/scratch-vm/issues/412#issuecomment-276168285 That was my first thought. I would advocate if we explore type of block, we should try out HSV/HSB as an alternative colors space to RGB.

We currently handle transparency within setting/changing a 'shade' value, which is kind of nice because transparency is not directly tied to a color value. Then again just another dimension to explore.

[thisandagain]

It makes sense being separated, but overloading "shade" to handle transparency feels a little odd to me. Might be something to talk through at our next design meeting.

[carljbowman]

Agreed. I misunderstood, I thought 'shade' only affected transparency. Super awkward that it controls both 'shade' and 'transparency'. Should explore separating those properties.

[cwillisf]

My first instinct is to settle on an internal string representation for color -- we could use the current semi-supported input format for the set color block if we want -- and then make a block which will generate that output from a color picker. The color picker could support RGB, HSL, HSV, or whatever combination of those things we feel comfortable with.

IMO the trickiest part of this would be making it compose well with other blocks. We'd have to decide what {color} + {1} means, for example. Does it add 1 to each channel of the RGB color? Does it add 1 to the hue component of an HSL/HSV color, for a similar effect to the change {color} effect by {1} block? Etc.

As for the color model: most of Scratch is already set up for hue and saturation, so I would recommend HSV or HSL for user-facing color representations. We might also want to go that way for internal storage in order to avoid accumulating error through constant conversions. This is one reason we might not want to stick with the current ARGB-based representation, though we'd then need to figure out what to do with the set color block for compatibility. I think we can solve that problem, though.

Also, the shade in pen blocks is used to generate the value component of the pen's HSV color; it doesn't affect transparency. The only way to get transparency on the pen is by plugging a reporter into the set pen color to {color} block and knowing that block parses the color as a 32-bit A8R8G8B8 value. (Note that the set pen color to {number} block sets the pen hue only.)

[thisandagain]

Good example project showing how many in the community accomplish RGBA for pen today:
https://scratch.mit.edu/projects/73673560

[cwillisf]

One argument against what I suggested above: currently the pen set color block is the only block where it makes sense to choose a semi-transparent color. Adding a new "type" (even if it is just a specific format of string) might be overcomplicating the situation when we could just add a slightly more sophisticated color picker to that particular block. Doing so would make it difficult to store a color in a variable, though maybe that's not a big deal. More importantly, I think, it's not clear to me how you might use this model to set a semi-transparent pen color based on the value of some variable.

Another option: a block to explicitly specify the pen's transparency, similar to the block for setting the pen hue and the one for setting pen shade (value). We might want to use the word ghost to match the graphical effects block.

[thisandagain]

Agreed. Straw-person proposal:

• Add two blocks to "Pen" category below "shade" blocks
  
  
  
  • change pen ghost by [10]
  
  
  • set pen ghost to [50]
  
  

I'm still not 100% on "ghost" as the term here, but that's another conversation. 😅

[TheBrokenRail]

Maybe for the [color] + 1 issue you chould use blockly "output" checks so it only fits in a set color block, and I like the set pen transparency/ghost idea.

[ghost]

If you're going to stick with the (color red: () green: () blue: () transparency: ()), you could replace the words "red", "green", "blue", and "transparency" with icons: a colored circle for each color () and a circle with checkered background () for the transparency. That'd shorten the block's length by a lot.

Then you could extend the current hue (set color with number input) and shade blocks by adding a saturation block, and support the whole HSL model. An unnecessary limitation I saw with those blocks is that you couldn't make white nor black with them, shade 0 and shade 100 only produce very light or very dark version of the chosen hue, respectively. A respective (color hue: () saturation: () shade: () transparency: ()) (icons: rainbow; gradient from red to white; gradient from black to white; checkered) would be nice too

And, finally and optionally you could add RYB and/or CMY because people are more familiar with subtractive color models. Although I feel like this last one is too much to ask, the previous two suggestions are what I'm looking for right now.

@TheBrokenRail It's probably the best option right now, but it might be a bit confusing unless Blockly has some kind of visual cue. But if we're going to keep compatibility it's probably best to do it like Scratch 2. I've seen a few projects that use (color) + 1 or similar. If someone tries it without knowing they'll probably just not understand what it's doing (and they'll probably not even try to understand it, since it doesn't make sense to add 1 to a color) and move on.

[thisandagain]

Decision from design discussion:

change pen transparency by [10]
set pen transparency to [50]

These blocks should be added to the bottom of the pen category block list.

[TheBrokenRail]

So would this request become for a RGB block?

[TheBrokenRail]

Should I make a separate request for a RB block?

[thisandagain]

Tracking implementation in https://github.com/LLK/scratch-gui/issues/602