Home > Back-end >  Why does the Canvas API fill parts of these paths within a loop with the wrong color?
Why does the Canvas API fill parts of these paths within a loop with the wrong color?

Time：10-27

I’ve created a Screenshot of an area with individual green squares arranged in a 16 by 6 grid. Each square contains a few vague black outlines. The last square in the bottom right corner has a properly filled black shape of an Ethernet port. This is referred to as “the port shape”.

However, if I comment out the green background, it does work like so, where the shapes are all filled in as you would expect.

Screenshot of the same 16 by 6 grid, but this time, there are no green squares. Every single cell in the grid is filled with a black “port shape”.

After posing the question, I was able to “solve” the issue by tweaking the relevant code segment to look like below:

ctx.beginPath(); // Added this line.

ctx.fillStyle = "black";
ctx.rect(x, y, portWidth, portWidth);
ctx.fill();

ctx.fillStyle = "green";

Screenshot of the same 16 by 6 grid, this time all black “port shapes” properly filled on top of green squares.

Basically, my initial attempt was “conceptually” trying to create a green square and then overlay a black shape on top of it. Something was going on weird with that so instead I created one continuous thing (Path? Shape?) composed of two nested things (I don’t know the right canvas terminology) with two separate fills, and then that somehow worked.

I’m not putting this as an answer since it isn’t, but it is how I have accomplished my desired effect for now.

CodePudding user response：

The simple fix for this issue is to replace A graphical explanation of the mechanisms in the table above is presented. The graphic has a dark gray background. Three simple polygons are shown in a row. The exact shapes do not matter, but the polygon on the left and the one on the right have four corners each, the one in the middle has three. A white curly bracket spans the left and middle polygon, and is labeled “Path”. Another white curly bracket spans the polygon on the right, also labeled “Path”. Three yellow curly brackets span each polygon individually, each one labeled “Subpath”. The white curly brackets are at the bottom, the yellow ones at the top. This is to demonstrate that the left and middle polygon are part of the same path, but split into two subpaths, whereas the polygon on the right is its own path and consists of a single subpath. Near the top left corner of the graphic is a brown point labeled “Origin”. A light gray arrow is connected from the origin to one of the corners of the polygon on the left. The arrow is labeled “moveTo”. Four more arrows travel from corner to corner to trace the outline of the polygon on the left. Each of these arrows is labeled “lineTo”, except the last one, which is labeled “closePath”. This means, the last arrow points to the same corner as the first “moveTo” arrow. From this point on, another arrow labeled “moveTo” connects to the polygon in the middle, where three more arrows trace out its outline with the labels “lineTo”, “lineTo”, and “closePath”, respectively. The label “beginPath” floats near that last corner. Another arrow labeled “moveTo” points to a corner of the polygon on the right, but the start of the arrow is invisible and transitions into visibility as it approaches the corner of the polygon on the right. This means that the arrow has a color gradient from transparent to light gray. This is to demonstrate that an entirely new path begins here and there is no real connection between the polygon in the middle and the polygon on the right, other than the fact that technically, the “moveTo” method does indeed come from the corner of the middle polygon. The final four edges of the polygon on the right are traced with arrows, again all labeled “lineTo”, except the last one, labeled “closePath”. All polygons are traced in the counterclockwise direction, although this doesn’t matter in practice. The “beginPath” label is white and matches the color of the “Path” label. The “moveTo” label is yellow and matches the color of the “Subpath” label. The “lineTo” and “closePath” labels are light green. This is to demonstrate the relation between different method calls and the creation of paths and subpaths. The arrows show in which order the paths and subpaths are created and in which order the vertices are added. The left and middle polygons are filled purple, the polygon on the right is filled dark red. Three “fill” labels are in the bottom row. The first one represents a “fill” call after the first “closePath” call: from the label, an arrow points inside the polygon on the left. The second “fill” label represents a “fill” call after the second “closePath” call: from the label, one arrow points inside the polygon on the left and another arrow points inside the polygon in the middle. The last “fill” label represents a “fill” call after the last “closePath” call: from the label, an arrow points only inside the polygon on the right. Each “fill” label and their respective arrows have a similar color to the respective fill colors of each polygon. This is to demonstrate that “fill” calls pertain to the entire current path, not to individual subpaths.

rect, like its related methods, adds to the current subpath.

The distinction between (entire) path and subpath is important, but easily missed: beginPath creates an entirely new path, and moveTo creates a subpath, but fill fills entire paths. Furthermore, what is filled once, stays filled. This is like paint: when you paint the canvas once, and are told to fill an overlapping region, you’ll have to paint over your older paint.

This helps explain why these black outlines exist: your port shapes are filled black, but then the same shape — plus a rectangle — are filled green; the green overlays the black. Note that division by 6 isn’t always very precise, so each fill has some transparency towards the edge. That’s why the green doesn’t completely cover the black at the edges.

It is important to note that closePath is not the “opposite” of beginPath. closePath doesn’t remove or add new paths or subpaths; it does not change which one the “current” path or subpath is. This is further complicated by the fact that beginPath and closePath are sometimes optional: for instance, a moveTo is only supposed to create a subpath, but if it’s called at the very beginning, when no path exists, a path is automatically created as well, making a beginPath before moveTo redundant.

Let’s go through the script step by step, by considering two iterations one after the other:

  1. First iteration
    1. ctx.fillStyle = "green"; sets the fill color for the next fill call to "green".
    2. ctx.rect(x, y, portWidth, portWidth); requires a subpath to exist. Since no paths exist at the beginning, a new path is automatically created, and a subpath is created as part of it. Then, a rectangle is added to the current subpath.
    3. ctx.fill(); fills the interior of the entire current path (the rectangle) green.
    4. ctx.fillStyle = "black"; sets the fill color for the next fill call to "black".
    5. ctx.beginPath(); discards the previous path and creates a new path. This is now the current path, and the previous rectangle path is no longer accessible.
    6. ctx.moveTo(x portSixth, y 2 * portSixth); creates a new subpath within which it moves the current position.
    7. The seven ctx.lineTo(…); calls add vertices to the current subpath.
    8. ctx.closePath(); is equivalent to a lineTo back to the start of the current subpath.
    9. ctx.fill(); fills the interior of the entire current path (the port shape) black.
  2. Second iteration (Steps 1 and 4 are no different than in the first iteration)
    1. (ctx.fillStyle = "green";)
    2. ctx.rect(x, y, portWidth, portWidth); adds a rectangle to the current subpath, which already exists and already includes the port shape of the previous iteration.
    3. ctx.fill(); fills the interior of the entire current path (the rectangle plus the port shape of the previous iteration) green.
    4. (ctx.fillStyle = "black";)
    5. ctx.beginPath(); discards the previous path and creates a new path. Now the rectangle plus port shape are no longer accessible.
    6. Etc.

The second iteration is where the bug happens. In its third step, fill fills a path that has been opened in the previous iteration using beginPath.

As you found out, you can fix it without fillRect, by simply placing ctx.beginPath(); before ctx.rect(); — or, equivalently, at the start of the iteration. Now you should understand why.

1: fill does indeed accept a specific Path2D as an argument. Without an argument, it fills the current path of the provided rendering context.

Page link：https//www.codepudding.com/Backend/167871.html

Prev:Can you set a value in CSS from another value?
Next:If-statement in a for loop in Django disappears when executing
  • Related

About Us:  Contact Us      Terms of Service       Privacy Policy

Copyright © 2010-2023，Powered By CodePudding