Why color? 0x00000000 Doesn't give a transparent color?

Processing
1

When I do:

stroke(0x00000000);

This does not give a transparent color.

(Yes, I know I can write 0,0)

The question is more about the consistency of API processing, since in many cases the processing itself transforms many values implicitly.

Why is this case not covered?

1 Like
2

Literal 0x00000000 is simply 0!
By default, any value within range 0 to 255 is interpreted as gray color:

For such case, we need to pass an extra 2nd alpha parameter:
stroke(0, 0); // transparent black

2 Likes
4

This does seem pretty weird. According to the docs, any 0x00000000 format hex number ought to be interpreted as 0xAARRGGBB, but as @GoToLoop said, if the AARRGG digits are zero then it interprets the BB digits as grayscale. eg. this creates a white circle:

size(400,400);
color c = 0x000000FF;
stroke(c);
noFill();
circle(200,200,50);

Granted, if you want fully transparent you have plenty of other values you can set the RGB values to that still work. But this still seems off, and doesn’t match any documentation I can see.

1 Like
5

Notice that 0x is Java syntax for hexadecimal literals.

While #rrggbb is Processing’s syntax for 100% opaque RGB colors; which is then converted to Java 0xFFrrggbb hexadecimal literal.

6

Yeah, I can see how it makes sense as an artifact of how colors are stored behind the scenes. It still doesn’t match how colors are described in the docs though.

Maybe descriptions of 0x color literals in the docs should have a footnote re: how 00 alpha values have a surprise in store?

1 Like
7

Yes, I understand.

But as we know, there are many aspects to processing. But as we know, there are many moments in processing where implicit transformations in values occur, something that could not be done in Java, at least not written in hex as "#AABBCCDDFF”.

It becomes unclear where processing additionally converts itself into the required value, and where to expect default behavior regarding colors, etc.

8 
img = loadImage("myImage.png");
img.format = ARGB;
9
  • On Processing’s IDE (PDE) we can write code on both “.pde” & “.java” files.
  • By default, the PDE creates a “.pde” file as a new tab; but we can explicitly append a “.java” extension to it.
  • When we hit the PDE’s run button, all “.pde” files are concatenated as 1 single file.
  • Then the PDE applies its “pre-processor”, which will convert that concatenated file to an actual Java syntax-valid file as 1 PApplet subclass!
  • That’s when non-valid Processing syntax stuff (like the # color literal, the keyword color, etc.) are transpiled to their corresponding Java valid syntax.
  • We can even check that new “.java” file created by the “pre-processor”, so we can learn how Processing syntax is transpiled to Java’s.
  • However, the “pre-processor” won’t syntactically touch any “tab” files w/ the “.java” extension; but they will be compiled together w/ the transpiled unified “.pde” files though.
10

The question is not how it works, the question is why such cases are not covered.

11

Well, I believe Processing’s devs believe we as users shouldn’t be bothered w/ such internal details.

What I’ve just explained I’ve learnt all by myself.

1 Like
12

Hello folks!

I am sharing some references to stroke(0x00000000) not giving a transparent color.

This is what is happening under the hood (other methods as well) and discusses why this breaks and the solution:

The reference (more than one function impacted) would certainly benefit from a comment highlighting this issue or link to the Wiki:
stroke() / Reference / Processing.org

This issue is mentioned in the Wiki:
Troubleshooting · processing/processing4 Wiki · GitHub

@sableraph Pleased to see that this was recently added to the website:

Lots of cool stuff in the Wiki!
Home · processing/processing4 Wiki · GitHub

Issues related to the website documentation are here:
GitHub · Where software is built

:)