🪵 4. Canvas 기본 기능 구현 주요 이슈

Canvas 터치 그리기 구현

• 관련 이슈 : #16
• 캔버스 터치 시 레이아웃 스크롤링이 활성화 되는 이슈와, MouseEvent와 TouchEvent가 제공하는 좌표 속성이 다른 이슈로 드로잉 구현에 추가 학습이 필요했습니다.

캔버스 터치 시 레이아웃 스크롤링 활성화

• 터치로 그리기 위해 캔버스를 슬라이드 했을 때, 화면 전체가 이동하는 이슈가 있었습니다.

해결법

1. css 속성에 touch-Event : none 추가합니다.
2. touch 이벤트 핸들러에 e.preventDefault() 추가하여 스크롤링 방지합니다.
   • 스와이프 동작 시 스크롤 방지와 UX 개선

과정

• 처음에는 2번 방법으로 해결하려 했지만, e.preventDefault()는 해당 이벤트의 모든 동작을 막아버리겠다는 의미로 알고 있었기에 무언가 찝찝했습니다.

• 더해서 직접 적용해보니 아래와 같은 경고가 발생했습니다.

  Canvas.tsx:113 Unable to preventDefault inside passive event listener invocation.

  

• 패시브 이벤트 리스너 호출 내에서 default를 방지할 수 없습니다. 라는 의미의 경고였습니다. 브라우저는 기본적으로 스크롤 성능을 최적화하기 위해 touchstart와 touchmove 이벤트를 패시브(passive) 이벤트 리스너로 설정합니다. 패시브 이벤트 핸들러 란 성능 향상을 위해 핸들러 내에서 e.preventDefault() 를 호출하지 않을 것을 브라우저 차원에서 보장하는 핸들러입니다.

• touchmove 의 경우 주로 모바일 환경에서 쓰이고, 모바일 환경에서는 스크롤 기능이 매우 중요하기 때문에, 스크롤 이벤트 발생 시 마다 e.preventDefault() 가 호출되었는 지 확인하는 절차를 생략하기 위해 패시브 이벤트 핸들러로 세팅되었다고 합니다.

• 위 설정을 off 하고 touch이벤트에서 다시 e.preventDefault()를 호출 가능하게 하려면, 아래 처럼 이벤트 핸들러를 붙이며 인자로 설정 객체를 하나 더 보내주면 됩니다.

    window.addEventListener('touchmove', handleTouchMove, { passive: false });

• 하지만 굳이 브라우저 차원에서 최적화를 위해 막아놓은 설정을 해제하고 싶지 않았습니다. css 속성으로 간편하게 사용 가능한 1번 방법을 사용하기로 결정했습니다.

  touch-Event : none 에 대한 조사는 chat-gpt에게만 물어보고 마무리하였습니다.

  • touch-Event : none 원리 알려줘
    • 기본 터치 동작 차단: touch-action: none을 설정한 요소에서는 브라우저가 스크롤, 확대/축소와 같은 터치 기반의 기본 동작을 실행하지 않습니다. 이 속성을 적용하면 터치가 발생해도 브라우저는 이 동작을 무시하고, 터치 이벤트만 JavaScript에서 수신할 수 있게 됩니다.
    • 브라우저 최적화: 보통 브라우저는 터치 이벤트가 발생할 때 기본 동작을 처리하기 위해 약간의 시간을 기다립니다. touch-action: none이 설정되어 있으면, 브라우저가 기본 동작을 미리 차단하고 기다리지 않기 때문에 더 빠르게 반응할 수 있습니다.
    • JavaScript로만 터치 동작 제어: 이 속성을 설정한 요소에서는 터치 동작을 완전히 JavaScript로 제어할 수 있습니다. touchmove, touchstart, touchend 이벤트를 활용해 터치 이벤트를 원하는 대로 처리할 수 있습니다.

MouseEvent와 TouchEvent가 제공하는 좌표 속성이 다름

• React는 nativeEvent 객체를 통해 캔버스 좌표를 기준으로 한 x좌표와 y좌표를 바로 보내줍니다. nativeEvent는 React의 SyntheticEvent 객체에서 브라우저 이벤트 객체 속성에 직접 접근하는 방법입니다. 하지만 터치 이벤트에는 이런 속성이 없어, 터치 시에도 그리기를 구현하기 위해서는 캔버스 위의 터치 지점을 직접 계산해줘야 했습니다.

• MouseDown의 경우 터치 했을 때도 작동하는데, 이는 브라우저가 터치 스크린 장치에서 터치를 마우스 입력으로 에뮬레이션하기 때문이라고 합니다. touchDown, touchEnd는 발생 시 브라우저가 터치 입력을 마우스 입력으로 알아서 전환해준다는 것입니다.

추후 과제

• SyntheticEvent, nativeEvent, TouchEvent, MouseEvent 간의 관계를 더 깊숙하게 스터디할 필요가 있습니다.
• mouseEvent, touchEvent, window, html 태그가 제공하는 좌표 속성들도 정확히 정리해 이해할 필요가 있습니다. (offsetX, clientX, getBound, getBoundingClientRect(), 그 외 기타 등등..)
• 아래는 touchEvent와 clickEvent 간의 관계에 대한 글입니다.
  • 터치와 클릭, 우리 깐부잖아

현재 구현 상태

• MouseEvent와 TouchEvent 둘 다 nativeEvent 객체를 통해 좌표를 받아오고 있습니다.

  • click : nativeEvent.offsetX, offsetY 사용
  • touch : nativeEvent.touches 사용

• touchEvent의 경우 아래 라인처럼 터치 좌표를 배열로 받아오게 되는데, 이는 터치 화면의 경우 터치점이 2개 이상 생길 수 있기 때문입니다.

  const { clientX, clientY } = e.nativeEvent.touches[0]; //뷰포트 기준 상대 좌표

참고 자료

• reactnative
• 합성 이벤트(SyntheticEvent)
• SyntheticEvent

캔버스 페인트 툴 기능 구현

• 관련 이슈 : #27

구현 계획

• getImageData 메소드를 통해 Canvas의 이미지 데이터를 가져올 수 있음을 활용합니다.
• 따라서 bfs 알고리즘으로 구현하기로 계획했는데, 검색해보니 Flood Fill 알고리즘이라고 이미 거의 정석으로 굳어진 방법이 있었습니다.
  • Flood Fill : 주어진 시작점으로부터 연결된 영역들을 찾아내는 알고리즘입니다. bfs를 활용하는 방식이 가장 보편적인 듯 했고, 따라서 기존 계획대로 bfs로 구현하기로 결정하였습니다.

시행 착오

• 초반 계획은 아래와 같았습니다.

  • getImageData는 Canvas 이미지 데이터를 rgba 값이 나란히 담긴 1차원 배열로 가져옵니다. 따라서 bfs 함수 내에서의 이동 좌표 단위는 다음과 같습니다.

    • x축 오른쪽으로 1 pixel 이동 : + 4
    • y축 아래로 1 pixel 이동 : + (canvas.width * 좌표y + 좌표x) * 4
    • 4를 더하고 곱해주는 이유는 rgba 값이 총 4개이기 때문.

  • 사용자가 클릭한 위치 또한 (canvas.width * 좌표y + 좌표x) * 4 공식으로 구할 수 있습니다. 그래서 해당 방법으로 캔버스의 어느 지점을 선택했는 지를 먼저 구한 후, 위 단위를 더하고 빼면서 픽셀칸을 탐색해가는 방식으로 구현해보았습니다.

    const movement = [4, CANVAS_SIZE * 4, -4, -CANVAS_SIZE * 4];
    
    while (searchArray.length > 0) {
      const currentIndex = searchArray.shift();
      //searchArray의 길이가 소진될 때 까지 반복
      
      for (const move of movement) {
        const nextIndex = convert(currentIndex! + move);
        //convert는 소수를 정수로 잡아주는 함수
    
        if (
          nextIndex >= 0 &&
          nextIndex < pixelArray.length &&
          !checkArray[nextIndex] &&
          checkColorisEqual(nextIndex, beforeColor, pixelArray)
    	    //index가 pixelArray 길이 안에 있으면서 방문한 적 없는 index이고,
    	    //클릭한 픽셀의 색이 index 위치의 색과 같으면 색칠 후 searchArray에 담는다.
        ) {
          checkArray[nextIndex] = true;
          fillTargetColor(nextIndex, targetColor, pixelArray);
          searchArray.push(nextIndex);
        }
      }
    }

• 하지만 위 처럼 구현하고 나니 원인을 파악하기 힘든 무한 루프가 발생했습니다. 짐작할 수 있는 원인은 다음과 같았습니다.

  • 1차원 배열 상에서 index를 더하고 빼는 방식이다보니 계산이 불명확합니다.
  • 혹시 4의 배수 단위 인덱스가 아닌 곳을 건드리면 오류가 발생할 수 있습니다.
  • checkArray위와 같은 이유로 제대로 동작하는지 파악하기가 힘듭니다.

• 문제 해결을 위해 1차원 배열의 좌표값을 사용하는 부분은 그대로 두고, checkArray 방문 배열을 2차원 배열로 만들어 탐색 완료 좌표들을 관리하기로 했습니다. 아래는 위 전략으로 수정한 코드입니다. 좌표 이동을 가상의 2차원 배열(checkArray)에서 관리해주고, 반복문 내에서 2차원 배열의 가상 좌표를 1차원 좌표로 변환해 사용하였습니다.

    const movement = [[1, 0],[0, -1],[-1, 0],[0, 1]];
  
  while (searchArray.length > 0) {
    const [currentX, currentY] = searchArray.shift()!;
    for (const move of movement) {
      const [nextX, nextY] = [currentX + move[0], currentY + move[1]];
      if (
        nextX >= 0 &&
        nextX < CANVAS_SIZE_WIDTH &&
        nextY >= 0 &&
        nextY < CANVAS_SIZE_HEIGHT &&
        !checkArray[nextY][nextX]
      ) {
        const nextArrayIndex = (nextY * CANVAS_SIZE_WIDTH + nextX) * 4;
        // 2차원 배열의 가상 좌표를 실제 1차원 배열의 좌표로 변환
        if (checkColorisEqual(nextArrayIndex, clickColor, pixelArray)) {
          checkArray[nextY][nextX] = true;
          fillTargetColor(nextArrayIndex, targetColor, pixelArray);
          searchArray.push([nextX, nextY]);
        }
      }
    }
  }

• 잘 작동했습니다.

개선사항

• 페인트 툴 사용 시 칠해진 영역 가장자리에 이전 색의 점선 흔적이 남았습니다. 다만 이 현상을 갈틱폰 같은 서비스에서도 발생하고 있어, 일단 최적화 단계에 살펴보는 것으로 미뤘습니다.

• 브라우저 창에서 아래와 같은 안내문이 발생하고 있습니다.

  Canvas2D: Multiple readback operations using getImageData are faster with the willReadFrequently attribute set to true. See: https://html.spec.whatwg.org/multipage/canvas.html#concept-canvas-will-read-frequently

  • 최적화에 대한 팁을 알려주고 있는 것인데, getImageData 메소드를 자주 사용하는 환경일 경우, Canvas2D 인스턴스를 willReadFrequently 옵션과 함께 가져와주면 성능이 향상될 수 있다는 내용입니다.
  • 브라우저는 canvas같은 그래픽 요소를 기본적으로 gpu를 사용해 렌더링합니다. 하지만 위 willReadFrequently 옵션을 사용할 경우 canvas는 cpu를 적극적으로 사용합니다.
  • cpu를 사용할 경우 gpu로 데이터를 옮기는 과정이 생략되어 더 빨라질 수 있다는 것이습니다.
  • 그래서 getImageData, toDataURL, toBlob 메소드가 빈번할 경우, 위 설정을 통해 cpu 처리를 권장한다는 내용이었습니다.
  • 자세한 내용은 아래 문서를 참고해보면 좋을 것 같습니다. 페인팅 기능이 그리 자주 쓰일까 싶어 코드에는 따로 적용하지 않았습니다. 성능 문제가 생기면 살펴볼 예정입니다.
    • HTML Standard

참고 자료

• canvas 사이즈 조절, 선 우둘투둘 현상 방지 팁에 대한 글