W3C home > Mailing lists > Public > public-html-ig-ko@w3.org > November 2010

Re: CANVAS 태그에 대한 질문을 시작으로 HTML5 KIG 활동을 시작해봅니다. ^^

From: Sunil Baek <sunil.baek@gmail.com>
Date: Sat, 20 Nov 2010 16:44:31 +0900
Message-ID: <AANLkTikev90SoyRTfVStRw8y6hdd9z3+gZ2Cdst+jjO+@mail.gmail.com>
To: Min Tae Kim <ibare77@gmail.com>
Cc: 김영보 <tonextday@gmail.com>, 이원석 <wslee@etri.re.kr>, Sangwhan Moon <smoon@opera.com>, public-html-ig-ko@w3.org
안녕하세요
메일링 리스트에 글쓰는건 처음이라, 이렇게 하면 제대로 올라가는건지 모르겠네요.

논의되는 내용과 크게 상관없는 내용인지는 모르겠습니다만,

canvas 에 context 의 내용을 image 객체로 저장하고,
image 를 다시 context 에 쓰는 기능이 있는걸로 알고 있습니다.

이정도 처리라면 크게 오버헤드를 걱정할 수준은 아니라고 생각됩니다.



2010/11/18 Min Tae Kim <ibare77@gmail.com>

> 안녕하세요. 이미지클릭 김민태입니다.
>
>
> canvas 와 svg  비교하여 예시를 주셨는데 저는 조금 다르게 생각합니다.
>
> 기본적으로 canvas 와 svg 는 최종적으로 렌더링된 이미지(?)를 브라우저 특정 화면에
> 보여준다는 것이 웹페이지를 보는 사용자의 입장에서는 유사하다고 볼 수 있지만 그
> 메커니즘은 전혀 다릅니다. svg는 그래픽 정보를 태그로 표현하고 그것을 실제로 파싱하여
> 화면에 드로잉 즉 렌더링 하는 역할은 브라우저의 SVG 렌더러가 처리하는 것입니다.
>
> 하지만 canvas 는 말씀하신 것과 같이 엘리먼트가 하나입니다. 단지 canvas 라는 그래픽 드로잉
> 영역을 개발자에게 제공만 해 줄 뿐 거기에 무엇이 그려지든 전혀 브라우저는 관여하지않습니다.
> 그렇기 때문에 canvas 하위 태그가 없는 것이며 무엇이든 그릴 수 있도록 점/선/면등의 드로잉을
> 할 수 있는 API 를 제공하는 것이겠지요.
>
> 이야기의 핵심은 랜더링 파트를 개발자가 코드로 개발해야 한다는 것이고 그렇기 때문에 canvas 의
> 사이즈가 변해서 그려지지 않는 새로운 캔버스가 나타난다면 그 부분만 개발자가 개발한 렌더링
> 파트에서 그려주면 되는 것이겠죠. 김영보님의 말씀중에 100 x 200 사이즈의 백그라운드가 파란색인
> canvas 가 300 x 300 으로 늘어나면 나머지 영역은 파란색으로 칠해져야할까? 라는 질문의 정답은
> 당연히 canvas 를 처리하는 브라우저는 아무런 동작도 안하는게 정답일겁니다. 왜냐하면 canvas
> 의 랜더링 파트는 브라우저의 역할이 아닌 개발자의 몫이기 때문입니다.
>
> 그래서 제가 최초 제시한 의문의 핵심은 canvas 의 사이즈 설정 만으로 canvas 컨텍스트 전체가 초기화
> 되는 방식이 과도하게 랜더러를 호출하는 문제를 발생시키는 것이 아닌가 하는 의문이었습니다.
>
> 컨텍스트의 사이즈가 변해서 변경된 사이즈 만큼 전체를 다시 그리던 혹은 다시 그려져야하는 영역만큼을
> 체크해서 해당 부분만 다시그려서 성능을 올리든 그것은 개발자의 몫이어야할텐데 canvas 의 작동 방식
> 때문에 이런 선태사항이 강제사항으로 변한게 아닌가 싶어서 말입니다.
>
>
> 오페라의 문상환님이 알려주신 내용으로도 사실 전 이런 방식으로 되어있는 것이 이해가 잘 안되고 있는 중입니다.
> 테스트 소스를 아직 다 보지는 못해서 의문을 더욱 더 진척시키지는 못하겠지만 일단 올려주신 소스들을
> 시간날때 면밀히 뜯어봐야할 것 같습니다.
>
> 다음번 KIG 미팅때 좀더 canvas에 대한 이해의 폭을 넓혀서 이야기할 수 있었으면 좋겠습니다. ^^;
>
>
>
> 오페라 소프트웨어 문상환
>>
>
> On Nov 17, 2010, at 4:50 PM, 김영보 wrote:
>
> 김영보입니다.
> 저는 다음과 같이 생각합니다.
>
> <canvas>는 <svg>와 달리 엘리먼트가 하나입니다.
> 즉, 모든 것이 이 안에 있다는 것입니다.
>
> <canvas> 크기가 100*200이면서 백그라운드 색이 파란색으로 되어 있다고 할 때
> 크기를 300*300으로 늘리면 늘려진 영역에 백그라운드 색을 파란색으로 칠해야 할까요? 아닐까요?
> 엘리먼트가 하나라면 칠해지는 것이 당연하다고 생각합니다만,
> 캔버스는 엘리먼트가 하나이기 때문에 늘려진 영역을 다른 영역이라는 개념으로 볼 수도 있습니다.
> <svg>로 생각하면 엘리먼트가 추가된 개념으로 생각할 수도 있습니다.
>
> 한편 <canvas>가 context 개념으로 이미지를 표현한다는 점에 대한 연구도 필요한 것 같습니다.
> 또한, 현 시점에서 이 메커니즘을 변경하면 지금까지 개발된 것이 문제가 된다고 생각합니다.
> 속성 값의 형태, 설정 방법을 바꾸는 기능 레벨이 아닌 메커니즘 레벨이기 때문입니다.
>
> 시간을 갖고 보다 많은 연구를 해서 의견을 제시해야 하는데,
> 문뜩 생각이 나서 적어 보았습니다.
> 생각을 달리하는 부분이 있으면 이해를 바랍니다.
>
>
> 2010년 11월 17일 오후 4:40, 이원석 <wslee@etri.re.kr>님의 말:
>
>> 안녕하세요. 문상환님.
>> 답변 감사합니다~
>>
>> 결과적으로 canvas 크기 설정에 따라 drawing buffer 크기가 결정되기 때문이라는 것인가요??
>>
>> 수고하세요~
>>
>> 이원석 드림.
>>
>> > -----Original Message-----
>> > From: public-html-ig-ko-request@w3.org [mailto:public-html-ig-ko-
>> > request@w3.org] On Behalf Of Sangwhan Moon
>> > Sent: Wednesday, November 17, 2010 4:09 PM
>> > To: public-html-ig-ko@w3.org
>> > Subject: Re: CANVAS 태그에 대한 질문을 시작으로 HTML5 KIG 활동을 시작해봅니다. ^^
>> >
>> >
>> > 안녕하세요, 오페라 소프트웨어 문상환입니다.
>> >
>> > HTML5 Working Draft 4.8.11 절의 하기 항:
>> >
>> > // 인용
>> >
>> > When the canvas element is created, and subsequently ***whenever the
>> width
>> > and height attributes are set (whether to a new value or to the previous
>> > value), the bitmap and any associated contexts must be cleared back to
>> > their initial state and reinitialized with the newly specified
>> coordinate
>> > space dimensions.***
>> >
>> > When the canvas is initialized, its bitmap must be cleared to
>> transparent
>> > black.
>> >
>> > // 인용 끝
>> >
>> > 에 명시되어 있습니다.
>> >
>> > 구현의 백그라운드는 스펙이 존재하기 이전에 아래 테스트 케이스 중 17, 18, 19번 로부터 시작
>> > 되었습니다.
>> >
>> > http://hixie.ch/tests/adhoc/html/canvas/
>> >
>> > 보시면 아시겠지만 4년이 넘은 test 들입니다. 사견이지만, HTML5 에디터와 동일인이 작성한
>> > 테스트이기 때문에 그에 대한 견해가 연장되었다고 생각됩니다.
>> >
>> > 이 부분에 대해서 WebGL에서 backbuffer가 아닌 전체 context의 초기화가 일어나는것으로 해
>> > 석되어서 잠시 논란이 있었으나, 하기와 같이 정리가 되었습니다.
>> >
>> > The drawing buffer into which the API calls are rendered shall be
>> defined
>> > upon creation of the WebGLRenderingContext object. ***The size of this
>> > drawing buffer shall be determined by the width and height attributes of
>> > the HTMLCanvasElement. Changing either of these attributes shall cause
>> the
>> > drawing buffer to resize and its contents to be cleared to (0,0,0,0).***
>> >
>> > 답변이 되었으면 좋겠습니다.
>> >
>> > 감사합니다.
>> > 문상환 배상
>> >
>> >
>> > 2010/11/17, 10:37 AM, Min Tae Kim 작성:
>> >
>> > > 안녕하세요.
>> > >
>> > > 이미지클릭 김민태입니다.
>> > >
>> > >
>> > > Canvas로 개발을 하다가 문득 의문이 생겨서 이렇게 질문드려봅니다.
>> > >
>> > > [질문]
>> > >
>> > > Canvas 태그는 width 또는 height 가 설정되면 (값의 변경 유무와 상관없이) canvas 자체
>> > 가 리셋됩니다.
>> > > 즉 그려진 이미지가 모두 지워지고 각종 style도 리셋됩니다.
>> > > 명시적인 API 로 reset 을 구현하지 않고 이렇게 하는 이유는 무엇일까요?
>> > >
>> > >
>> > > [배경]
>> > >
>> > > HTML5에서 새로 추가된 태그인 Canvas 는 많은 API 를 함께 제공하고 있습니다.
>> > > 2D 작업을 하기위해서 나름 충분한 API 를 제공하고 있는데요 유독 이해하기 힘든
>> > > 형태를 하나 발견했습니다.
>> > >
>> > > Canvas 자체의 width 또는 height 가 설정되면 Canvas가 Reset 되는 방식이 그것입니다.
>> > > 여기서 핵심은 실제로 Canvas 의 width나 height 가 변하지 않아도 단지 같은 크기로
>> > > 설정만 된다해도 Reset 되는 방식이라는 것이죠.
>> > >
>> > > Canvas.reset() 같은 API 를 제공해주면 더 명시적이고 좋을 것 같은데 개발 코드도 좀
>> > > 쌩뚱맞아지고 별로 훌륭한 컨셉인 것 같지는 않아서 말이죠.  혹시 왜 이런 메커니즘을 채택
>> > > 했는지 아시는 분이 있으시면 좋겠습니다.
>> > >
>> > > 그리고 무엇보다 단지 방식의 문제가 아닌 canvas 의 사이즈가 변하면 reset 이 되기 때문에
>> > > 만약 고정크기 Canvas를 사용하지 않는다면 브러우저의 크기가 변하면 항상 현재 상태의
>> > > Canvas 를 유지하기 위해서 다시그려야하는 부담감이 있습니다.
>> > >
>> > > 그려야하는 이미지가 복잡할 경우 이는 더욱 큰 부담이 될 것 같습니다. 만약 이렇게 reset
>> > > 되지 않는다면 리사이즈로 인해서 빈 공간만 다시 그리면 될텐데 현재의 canvas 구조상
>> > > resize 이벤트에 전체를 다시 그리려야합니다.
>> > >
>> > >
>> > >
>> > >
>> > > 우선 저는 이 질문으로 시작해봅니다.^^
>> > >
>> > > 김민태 드림.
>> > >
>> > >
>> > > ps : 메일 형식은 SK Telecom 김도완님의 양식을 활용해봤습니다. ^^
>> > >
>> > >
>> > > # Kim Min Tae
>> > > --------------------------------------
>> > > Imageclick co.,Ltd
>> > > http:// www.imageclick.com
>> > > ibare77@gmail.com
>> > > http://www.ibare.kr
>> > > http://twitter/ibare
>> > > Mobile: 010.8555.3198
>> > >
>> >
>> > --
>> > Sangwhan Moon <smoon@opera.com>, Opera Software ASA
>> > Skype: innodb1 | Mobile: +372-5971-6147
>> >
>>
>>
>>
>
> # Kim Min Tae
> --------------------------------------
> Imageclick co.,Ltd
> http:// www.imageclick.com
> ibare77@gmail.com
> http://www.ibare.kr
> http://twitter/ibare
> Mobile: 010.8555.3198
>
>
Received on Monday, 22 November 2010 07:37:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 November 2010 07:37:14 GMT