Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #37514 > unrolled thread

Re: Problem drawing lines on a canvas element

Back to article view | Back to comp.lang.javascript

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Problem drawing lines on a canvas element Alan <araskin@gmail.com> - 2019-10-08 21:46 -0400
    Re: Problem drawing lines on a canvas element dr.j.r.stockton@gmail.com - 2019-10-09 02:25 -0700
      Re: Problem drawing lines on a canvas element dr.j.r.stockton@gmail.com - 2019-10-11 15:41 -0700
        Re: Problem drawing lines on a canvas element Alan <araskin@gmail.com> - 2019-10-11 22:44 -0400
          Re: Problem drawing lines on a canvas element dr.j.r.stockton@gmail.com - 2019-10-12 15:50 -0700
            Re: Problem drawing lines on a canvas element "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-10-12 20:36 -0700
              Re: Problem drawing lines on a canvas element luserdroog <luser.droog@gmail.com> - 2019-10-12 22:14 -0700

#37514 — Re: Problem drawing lines on a canvas element

Your

CX.beginPath()

in the

if (Main) {}

block should be inside the for loop instead of before it.

- Alan

On 08/10/2019 5:33 p.m., dr.j.r.stockton@gmail.com wrote:
> I think there must be a conceptual point about drawing
> to a canvas which I have forgotten.  This example is not
> important of itself, but elsewhere on the same canvas I
> have a more complicated, but maybe similar, situation in
> a more important part of the drawing.
> 
> If this one can be explained, then maybe I can see how
> to deal with the other.
> 
> There are ten parallel pipes carrying cold water, and
> each has a stop valve.  The following code is intended
> to draw them.  Global variables w & h are scaling factors;
> CX is the Context.
> 
> The code writes to the correct parts of the screen, BUT
> the colour is not always as expected.  All parts are
> blue = "Cold", EXCEPT for the handle of the last StopValve
> ONLY, which is black - I wanted all handles to be black.
> 
> The previous item drawn was green; the following was blue
> or white.
> 
> 
> function Sphere(CX, X, Y, Radius, Hue) { X *= w ; Y *= h ; Radius *= w
>    CX.save()
>    CX.fillStyle = Hue
>    CX.beginPath()
>    CX.arc(X, Y, Radius, 0, 2*Math.PI, 0)
>    CX.fill()
>    CX.restore() }
> 
> 
> function StopValve(CX, X, Y, Radius, Hue, Theta) {
>    CX.save()
>    Sphere(CX, X, Y, Radius, Hue)
>    X *= w ; Y *= h ; Radius *= w
>    Radius *= 1.7 ; Theta *= Math.PI/180
>    CX.strokeStyle = Coal
>    CX.beginPath()
>    CX.moveTo(X, Y)
>    CX.lineTo(X += Radius*Math.sin(Theta), Y -= Radius*Math.cos(Theta))
>    Radius /= 2
>    CX.lineTo(X + Radius*Math.cos(Theta), Y + Radius*Math.sin(Theta))
>    CX.lineTo(X - Radius*Math.cos(Theta), Y - Radius*Math.sin(Theta))
>    CX.stroke()
>    CX.restore() }
> 
> // Initialise CX, h, w
> // Do some drawing
> 
>    if (Main) {
>      CX.strokeStyle = Cold
>      CX.beginPath()
>      for (J=0 ; J<10; J++) { T = (350+30*J)*h
>        CX.moveTo( 20, T)
>        CX.lineTo(210, T)
>        CX.stroke()
>        StopValve(CX, 50, T/h, 6, Cold, 45) }
>      }  // Main
> 
> // more drawing
> 
> 
> ASIDE:  BTW, is there a Unicode character that CX.FillText
>          could use to represent an old-type television receiving
>          aerial? - not a dish, but a contraption of rods ? I
>          know how to put a 16-bit character into a string, but
>          not how for the newer extended-code sort.
> 

[toc] | [next] | [standalone]

#37521

On Wednesday, 9 October 2019 02:45:28 UTC+1, Alan  wrote:
> Your
> 
> CX.beginPath()
> 
> in the
> 
> if (Main) {}
> 
> block should be inside the for loop instead of before it.

Yes - thanks.

I'll look for an analogous situation for my maybe-related other problem.


-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [next] | [standalone]

#37525

On Wednesday, 9 October 2019 10:26:02 UTC+1, dr.j.r...@gmail.com  wrote:
> On Wednesday, 9 October 2019 02:45:28 UTC+1, Alan  wrote:
> > Your
> > 
> > CX.beginPath()
> > 
> > in the
> > 
> > if (Main) {}
> > 
> > block should be inside the for loop instead of before it.
> 
> Yes - thanks.
> 
> I'll look for an analogous situation for my maybe-related other problem.

The situation seems to be with the following, in which the loop builds a path
which is essentially a not-necessarily-closed irregular polygon, and I want the next statement to draw the path in the colour "Hue".  What seems to be happening is that, when Sinuous is called several times in succession with varying Hue, the colours are applied to incorrect sinuosities.

If there is an obvious error and fix, I'll apply them; otherwise, more testing is needed.

function Sinuous(Hue /* ,[,],[,] ... */) { // Stroke a sequence -
  // undefined array element means "as before", 0/1 means off/on
  var J, K, L = arguments.length, Line = false, X, Y
  CX.save()
  CX.strokeStyle = Hue
  CX.beginPath()
  for (J = 1 ; J < L ; J++) { K = arguments[J] // alert(K)
    if (isFinite(K[0])) X = K[0] ; if (isFinite(K[1])) Y = K[1]
    if (isNaN(X) || isNaN(Y)) alert("Sinuous: bad argument #" + (J+1))
    if (K != 0) Line ? CX.lineTo(X*w, Y*h) : CX.moveTo(X*w, Y*h)
    Line = K != 0 }
  CX.stroke()
  CX.restore() } // end Sinuous


-- 
   (c) John Stockton, near London, UK.  Using Google Groups.           |
  Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [next] | [standalone]

#37526

On 11/10/2019 6:41 p.m., dr.j.r.stockton@gmail.com wrote:
> On Wednesday, 9 October 2019 10:26:02 UTC+1, dr.j.r...@gmail.com  wrote:
>> On Wednesday, 9 October 2019 02:45:28 UTC+1, Alan  wrote:
>>> Your
>>>
>>> CX.beginPath()
>>>
>>> in the
>>>
>>> if (Main) {}
>>>
>>> block should be inside the for loop instead of before it.
>>
>> Yes - thanks.
>>
>> I'll look for an analogous situation for my maybe-related other problem.
> 
> The situation seems to be with the following, in which the loop builds a path
> which is essentially a not-necessarily-closed irregular polygon, and I want the next statement to draw the path in the colour "Hue".  What seems to be happening is that, when Sinuous is called several times in succession with varying Hue, the colours are applied to incorrect sinuosities.
> 
> If there is an obvious error and fix, I'll apply them; otherwise, more testing is needed.
> 
> function Sinuous(Hue /* ,[,],[,] ... */) { // Stroke a sequence -
>    // undefined array element means "as before", 0/1 means off/on
>    var J, K, L = arguments.length, Line = false, X, Y
>    CX.save()
>    CX.strokeStyle = Hue
>    CX.beginPath()
>    for (J = 1 ; J < L ; J++) { K = arguments[J] // alert(K)
>      if (isFinite(K[0])) X = K[0] ; if (isFinite(K[1])) Y = K[1]
>      if (isNaN(X) || isNaN(Y)) alert("Sinuous: bad argument #" + (J+1))
>      if (K != 0) Line ? CX.lineTo(X*w, Y*h) : CX.moveTo(X*w, Y*h)
>      Line = K != 0 }
>    CX.stroke()
>    CX.restore() } // end Sinuous
> 
> 

Your code seems to work fine for me. Please provide the actual, 
problematic Sinuous() calls you are using.

(I only read newsgroups once in the evening, so feel free to continue 
this discussion via email for a more prompt response.)

- Alan

[toc] | [prev] | [next] | [standalone]

#37534

On Saturday, 12 October 2019 03:42:59 UTC+1, Alan  wrote:

> Your code seems to work fine for me. Please provide the actual, 
> problematic Sinuous() calls you are using.
> 
> (I only read newsgroups once in the evening, so feel free to continue 
> this discussion via email for a more prompt response.)

Ah, but when is the evening? ... Ah, I see that you are four hours behind GMT.  

I reduced the code by throwing out, piece by piece, all that seemed irrelevant, and reached, after initialising code, what follows :-
 
  Sinuous("blue", [550,650], [400,])

  if (F.GG.checked) {
   CX.beginPath()                // <--- That was absent.  OK now.
   CX.strokeStyle = "red"
   CX.moveTo(10, 300)
   CX.lineTo(470, 300)
   CX.stroke() }

IMHO, there should be an endPath method (which sets the Path to ReadOnly) which a programmer could use to defend against this error, but I've not yet seen one.

Thanks again.

-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [next] | [standalone]

#37535

On Saturday, October 12, 2019 at 5:50:25 PM UTC-5, dr.j.r...@gmail.com wrote:

> IMHO, there should be an endPath method (which sets the Path to ReadOnly) which a programmer could use to defend against this error, but I've not yet seen one.

https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/closePath

[toc] | [prev] | [next] | [standalone]

#37536

On Saturday, October 12, 2019 at 10:36:47 PM UTC-5, Michael Haufe (TNO) wrote:
> On Saturday, October 12, 2019 at 5:50:25 PM UTC-5, dr.j.r...@gmail.com wrote:
> 
> > IMHO, there should be an endPath method (which sets the Path to ReadOnly) which a programmer could use to defend against this error, but I've not yet seen one.
> 
> https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/closePath

This doesn't do what OP is asking (wishing) for. 'closePath' just adds
a line segment from the last point to the most recent 'moveTo' point,
ensuring that they coincide exactly. The hypothetical 'endPath' OP 
describes would prevent you from adding additional segments to the 
current path until 'beginPath' is called again.

I don't have the expertise to advise on whether this can be added using
inheritance or whatever. But if you wrap the whole API, it could certainly
be implemented in the wrapper layer.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web