# Problem with Stroke Transparency in Plotting Points

**URL:** <https://discourse.processing.org/t/problem-with-stroke-transparency-in-plotting-points/31313>\
**Category:** Processing.py\
**Created:** [July 18, 2021, 1:44am UTC](https://discourse.processing.org/t/problem-with-stroke-transparency-in-plotting-points/31313 "2021-07-18T01:44:33Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![javagar](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/javagar/32/11434_2.png) [@javagar](https://discourse.processing.org/u/javagar)\
**Post date:** [July 18, 2021, 1:44am UTC](https://discourse.processing.org/t/problem-with-stroke-transparency-in-plotting-points/31313/1 "2021-07-18T01:44:33Z")

</div>

I have encountered a problem with the `alpha` color component when experimenting with plotting points to represent Collatz orbits. See [Wikipedia: Collatz conjecture](https://en.wikipedia.org/wiki/Collatz_conjecture).

This code does what is expected:

```auto
# plots Collatz orbits for numbers 1 to width - 1
def setup():
    size(360, 360)
    background(0)
    noLoop()
    noFill()
    strokeWeight(1)
    
    # stroke with and without transparency
    # stroke(255, 254) # -> misses some points
    stroke(255, 255) # -> draws all points
    
    noSmooth()

def draw():
    # plot each x, y where is y is in the orbit of x
    for x in range(1, width):
        c = collatz(x)
        for y in c:
            point(x, y)

def collatz(n):
    # returns Collatz orbit for n, as a list
    c = [n]
    # terminate orbit at 1
    while n > 1:
        if n % 2 == 0:
            # even number
            n //= 2
        else:
            # odd number
            n = 3 * n + 1
        c.append(n)
    return c

```

Here’s the result:  
 ![collatz_orbits_alpha_255](https://canada1.discourse-cdn.com/flex036/uploads/processingfoundation1/original/2X/d/dcb88298b092cea6763cbe5921b591146e08b970.png)

Note this statement:

```auto
    stroke(255, 255) # -> draws all points

```

If I comment out that statement and uncomment the previous one to use this statement, which reduces `alpha` to `254`, the result is quite different:

```auto
    stroke(255, 254) # -> misses some points

```

The result becomes:  
 ![collatz_orbits_alpha_254](https://canada1.discourse-cdn.com/flex036/uploads/processingfoundation1/original/2X/d/d73061d74001da60993a4d5ed0664beaa976b40c.png)  
Many points are missing.

I have performed much experimentation, and found ways to work around this problem. For instance, using squares consisting of a single point, utilizing fill with transparency and no stroke, produces the desired result. However, I would still like to understand why reducing the `alpha` component from `255` to `254`, when plotting points, causes the observed problem.

In case it matters, I am doing this on an old MacBook Air with El Capitan.

_The title of this discussion was edited on July 20, 2021._

---

<div class="post-metadata">

**Author:** ![tabreturn](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/tabreturn/32/3697_2.png) [@tabreturn](https://discourse.processing.org/u/tabreturn)\
**Post date:** [July 18, 2021, 5:14am UTC](https://discourse.processing.org/t/problem-with-stroke-transparency-in-plotting-points/31313/2 "2021-07-18T05:14:18Z")

</div>

It seems this issue isn’t restricted to Python mode. These two code listings produce the same result (depicted below):

_Java mode_

```java
size(360, 360);
background(0);
stroke(255, 254);
noSmooth();

for(int x=0; x<5000; x++) {
    point(random(width), random(height));
}

```

_Python mode_

```python
size(360, 360)
background(0)
stroke(255, 254)
noSmooth()

for x in range(5000):
    point(random(width), random(height))

```

Interestingly, it’s the same areas of the screen (as your sketch) that are blank:

![Screenshot from 2021-07-18 17-05-56](https://canada1.discourse-cdn.com/flex036/uploads/processingfoundation1/original/2X/1/1feead50e1b4c084db86cddc9c377ee833689c28.png)

I deleted the `noSmooth()`, which solved the problem – I figured it’s something to do with how Processing handles strokes. So I re-added `noSmooth()` and tried a `strokeCap(PROJECT)`, which works.

---

<div class="post-metadata">

**Author:** ![javagar](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/javagar/32/11434_2.png) [@javagar](https://discourse.processing.org/u/javagar)\
**Post date:** [July 18, 2021, 10:18am UTC](https://discourse.processing.org/t/problem-with-stroke-transparency-in-plotting-points/31313/3 "2021-07-18T10:18:09Z")

</div>

> [@tabreturn](#):
>
> … tried a `strokeCap(PROJECT)` , which works.

Thanks, that does the job. Just to be safe, I took a close look to make sure it draws points at the correct pixels, rather than at neighboring ones, and it did place the points at the correct locations.

> [@tabreturn](#):
>
> It seems this issue isn’t restricted to Python mode.

Yes, since it’s Jython, and Processing is based on Java, that seems to make sense.

Since p5.js is JavaScript, independent of Processing Java Mode, I translated it to p5.js. Here is the code without `strokeCap(PROJECT)`:

```auto
// Plot Collatz Orbits
function setup() {
    createCanvas(360, 360);
    background(0);
    noLoop();
    noFill();
    strokeWeight(1);
    
    // stroke with and without transparency
    stroke(255, 254);
    // stroke(255, 255);
    
    noSmooth();
}

function draw() {
    // plot each x, y where is y is in the orbit of x
    for (let x = 1; x < width; x += 1) {
        c = collatz(x);
        for (let i = 0; i < c.length; i += 1) {
            point(x, c[i]);
        }
    }
}

function collatz(n) {
    // returns Collatz orbit for n, as an Array
    let c = [n];
    // terminate orbit at 1
    while (n > 1) {
        if (n % 2 == 0) {
            // even number
            n = n / 2;
        } else {
            // odd number
            n = 3 * n + 1;
        }
        c.push(n);
    }
    return c;
}

```

As expected, it also works.

---

<div class="post-metadata">

**Author:** ![soegaard](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/soegaard/32/13657_2.png) [@soegaard](https://discourse.processing.org/u/soegaard)\
**Post date:** [July 18, 2021, 10:54am UTC](https://discourse.processing.org/t/problem-with-stroke-transparency-in-plotting-points/31313/4 "2021-07-18T10:54:50Z")

</div>

@javagar: Yes, @tabreturn is right.

FWIW It seems that `point` in the various ports of Processing doesn’t handle the cap in the same way.

> <https://github.com/processing/p5.js/issues/5301>
>
> \#### Most appropriate sub-area of p5.js?
> 
> \- \[\] Accessibility (Web Accessibili…ty)
> \- \[\] Build tools and processes
> \- \[\] Color
> \- \[x \] Core/Environment/Rendering
> \- \[\] Data
> \- \[\] DOM
> \- \[\] Events
> \- \[\] Friendly error system
> \- \[\] Image
> \- \[\] IO (Input/Output)
> \- \[\] Localization
> \- \[\] Math
> \- \[\] Unit Testing
> \- \[\] Typography
> \- \[\] Utilities
> \- \[\] WebGL
> \- \[\] Other (specify if possible)
> 
> \#### Details about the bug:
> 
> \- p5.js version: the one online 7. june
> \- Web browser and version: Chrome 90.0.4430.212 
> \- Operating System: MacOSX
> \- Steps to reproduce this:
> 
> \`\`\`
> function setup() {
> createCanvas(200, 100);
> }
> 
> function draw() {
> background(220);
> strokeWeight(10);
> strokeCap(ROUND);
> point(50,50);
> strokeCap(SQUARE);
> point(100,50);
> strokeCap(PROJECT);
> point(150,50);
> }
> 
> \`\`\`
> The expected behaviour: the project cap ought to give a square and the square cap ought to draw nothing.
> 
> Compare with the description of point() for the Java version.
> https://processing.org/reference/point\_.html

I still think it is odd, that you see such a big difference between stroke(255, 255) and stroke(255, 254).  
Since the Python version needs to be consistent with itself - maybe it is a bug?

In any case, the documentation of `point` in Processing.py ought to say something about caps.

---

<div class="post-metadata">

**Author:** ![javagar](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/javagar/32/11434_2.png) [@javagar](https://discourse.processing.org/u/javagar)\
**Post date:** [July 18, 2021, 11:05am UTC](https://discourse.processing.org/t/problem-with-stroke-transparency-in-plotting-points/31313/5 "2021-07-18T11:05:30Z")

</div>

> [@soegaard](#):
>
> … maybe it is a bug?

Yes, the sketch with `alpha` set to `254` should hardly look different from the one with `alpha` set to `255`.

I had tried much lower `alpha` values, with the same unfortunate results as with a value of `254`. I was plotting points using a variety `strokeWeight` settings, in order to play with translucent overlaps, and when I chose a `strokeWeight` of `1`, the problem became evident.