Graphics and Skia

 Why Skia? 

•  GDI 는 SVG, Canvas, 복잡한 UI처리에 full-featured로 충분하지 못하다. 

•  SKIA 는 google이 needs에 맞게 수정 가능하다.
• There was already a high-quality Webkit/Canvas port to Skia.
• GDI+는 더이상 MS에의해 개발되어지지 않으며,  대부분의 동작에서 SKIA보다 느리다. 
• GDI+ text 렌더링은 GDI text 렌더링과 호환 되지 않는다. 
  

Background: What's with all these Canvii?

 

The Lowest levels

• Ÿ SKIA는 여러 Canvas 클래스들이 사용되고 있다. 가장 하단 레벨은 SkCanvas이다. (third_party/skia/include/SkCanvas) 이 오브젝트는 draw를 위한 모든 method를 포함하고 있다. Canvases는 SkBitmap object의 wrapper인 internel SkDevice에 그려진다. SKIA는 또한 text를 그리기 위한 function들도 포함한다. 이것은 chrome에서 지원되지 않는 것이다. Windows GDI에서 text drawing을 하여 Freetype을 사용한 SKIA font인 Cleartype을(Cleartype-quality antialiasing을 지원하지는 않음) 얻을 수 있다.
  

•  Windows를 사용할때 우리는 플랫폼 종속적인 native SKIA의 래퍼, SkPlatformCanvas(in SkPlatformCanvas.h))를 부른다. 그것의 뒤에, Skia와 Windows가 공유하는 메모리(HDC가 wrapping한 bitmap을 사용하기 위해 HBITMAP을 만들때 메모리)를 포함한 SkPlatformDevice가 적재되어 있다. 이 방법을 통하여, 우리는 SKIA로 Windows에서 text를 그릴 수 있다.
  

• SkPlatformDevice는 BeginPlatformPaint( draw할 수 있는 HDC를 리턴)와 native drawing 부분을 wrap한 영역을 사용하는 EndPlatformPaint, 두 가지 함수를 가지고 있다. 그들은 필요한 flushing을 관리하여, SKIA와 GDI가 일관된 bitmap을 보도록 허용한다. HDC를 리턴하는 rendering을 할때는 매우 조심스럽다. 아래의 comment를 주시하라.

 

The Application Layer

•  Webkit 레이어를 위하여, SkCanvas와 SkPlatformCanvas만 사용된다. 호출자는 text drawing 셋업을 매뉴얼하게 OK로 지정해야 한다. 왜냐하면, 모든 그래픽 operation은 하나의 그래픽 레이어로 향하게 되고, GraphicsContext를 사용하게 된다.

•  만약 browser process에서 동작하는 code를 작성할 때, (예를 들어, tab strip이나 view를 그릴때) higher-level의 option을 사용하게 된다.  또한 이 layer에서  SkPlatformCanvas로 ChromeCnavas를 지원한다. 이것은 매뉴얼한 GDI를 사용하는 것보다 편리한 text-drawing을 제공하고, SkScalar 좌표계 대신에 integer 값을 사용한 원시적인 그래픽루틴을 래퍼한다. 이러한  integer래퍼들은 중요한 단어에 "Int"로 수식어가 붙어 DrawRectInt와 같이 사용된다. 

Which canvas should you use?

• 만일 GDI를 사용할 필요가 없고, 오직 canvas에서 screen 대신에 다른 canvas로 카피한다면, SkCanvas를 다이렉트로 써라. 그게 더 빠르다.
  renderer안에서 사용할 때, SkCanvas가 불 충분 하다면,  SkPlatformCanvas을 사용해야 한다. Webkit 안쪽에서,  항상 이러한 인터페이스를 쓰게 될것이다. - Graphics Context, instead.

  모든 브라우저 레벨 코드에서 SkCanvas보다 기능적인 것들이 필요할때 ChromeCanvas를 쓰게 될것이다. Views system은 앞쪽에서 이야기한 겉과 같은, 중간적인 결과들을 제외한 ChromeCanvas 만을 말한다.
  

 

 

Scalar values

•  Skia는 대부분의 루틴에 쓰이는 좌표계 커스텀 타입인, SkScalar를 사용한다. 이 값은 compiler flag 값에 의존적으로, typedef된 floatfor floating-point 모드이거나, fixed-point 모드의 int이다. fixed-point mode에서는 상위 16-bits를 수의 whole part로 재구성하고, 하위 16-bit는 factional part로 재구성 된다. 비록 현재 floating-point mode로 컴파일 될 지라도, 바꾸기 원한다면, option을 열어 fixed point 변경하면 된다. 그러므로 매우 조심해야 하며, 이러한 함수들에 integer와 floating point 값을 바로 사용하지 말아야 한다. 

• wrapper를 가진 일반적인 함수들중 하나를 사용 할 때, 가장 쉬운 방법은 ChromeCanvas에서 제공하는 *Int function을 사용하는 것이다. option이 없다면, SkIntToScalar 나 SkFloatToScalar를 사용하여 값(int 나 float, 각각)을 사용할 SkScalar type으로 컨버트 해야한다. scalars를 int로 되돌리기 위한 convert는 SkScalarRound를 사용한다.
  
  
  

   

 

The epic battle of RGBA and BGRA

• Windows와 SKIA 둘다 각각 32-bit word의 RGBA 색상을 사용한다. Pentium과 같은 little-endian 머신의 메모리에 쓰여질때, 이것은 BGRA가 된다. 이것은 시스템 밖에서, 또 데이타를 가져올때 약간의 문제를 야기한다. libpng나 libjpeg과 같은 많은 graphics 라이브러리들은, 머신 endian을 고려하지 않고 RGBA를 사용하길 원한다. 

• 결론적으로 이러한 시스템 인터페이스에 의하여 byte가 뒤죽박죽되지 않도록 조심해야 한다. PNGEncoder나 PNGDecoder, 그리고 JPEGCodec과 같은 application-level graphics codecs은 이런것을 지원한다...
  

 

 

Opacity

•  Windows와 SKIA 모두 single buffer에 draw하는 것을 최고로 생각한다. Windowse는, 하지만 , alpha channel을 모른다. 대부분의 GDI 명령들은 상위 8 bit를 그저 padding으로 비워 둔다.
  
  

 

Premultiplied alpha channels

• SKIA가 Premultioplied color를 사용할 수 있는것을 아는것은 중요하다. 이것은 color components가 alpha channel에 의해 곱하여진 것을 의미한다. 대부분의 사람들은 색상과 opacity 값을 분리 하는 생각에 익숙하다. Premultiplied colors는, alpha에 의한 곱셈이 더하여진 layer들을 혼합(composit)하는  "Composited on black"  방식으로 처리되어 진다. 그러므로 alpha가 50%라면, 색상 채널은 50%보다 크게 된다.

• 대부분의 그래픽 파일 포맷들이 postmultiplied alphas(칼라 값에 색상이 분리된 알파가 더해진 형태)를 사용한 이래로, 이러한 시스템의 reading과 writing 시의 두포맷 사이를 적당히 컨버트 해주어야 한다.

• SkPreMutiplyColor는 SkColor를 premultiplied color value로 바꿔준다. (SkPMColor)
  

 

 

The Case of the disappearing alpha

• Window는 alpha channel에 의해 알수 없는 몇몇 문제가 야기된다. When rendering text, it inconveniently sets the alpha channel to 0 (transparent).  왜냐하면 color values는 premeultiplied color가 아니기 때문이다. UI와 Webkit port에서 이것들을 다루기 위하여 접근한다. 훗날 이것들을 합치거나 향상시킬 것이다.
  
  

 

Transparency in the Webkit port

• 웹 페이지는 렌더 속성을 위하여 임의의 투명도를 요구하지 않는다. web page는 fully 불투명 기반이다. 몇몇 이미지 포맷은 alpha 채널을 지원하지만, 이것은 불투명 배경과 혼합되고, 특별한 hadling이 필요하지는 않다. web page가 투명하게 만드는 오직 한가지 방법은, element상에 global transparency 설정을 해주는 것이다. 그러므로, 임의의 투명도를 지원할 필요가 없고, 오직 1-bit mask의 layer를 컴포짓 하는 것으로 불투명 지역에서 모든 투명 지역을 분리시킬 수 있다.

• 투명도를 지원하는 새로운 SkPlatformDevice들은 그들의 값을 premultiplied alpha 사용이 가능한 색상으로 채운다. 웹킷은 일반적으로 불투명 색상이 가장 상위에 있알파 채널을 잠재적으로 클리어하고 text drawing routines를 사용한다. 레이어가 혼합될 때 , color를 fixupAlphaBeforeCompositing을 alpha channel로 바꾸고 혼합시킨다. The thing to realize here is that this operation is destructive and the device will be invalid if used again.
  

 

Transparency in the UI

• UI에서, 더욱 복잡한 알파 채널을 원할 때가 있다. finer-grained conrol을 제공하여 prepareForGDI와 postProcessGDI를 사용하여 GDI를 호출하여 alpha를 망치기 전, 후의 사각형 지역을 호출 할 수 있다. 그것은 transparent 값을 불가능한 색상으로 교체하는 것과 비슷하다. GDI에 의해 그려지는 모든 픽셀은 불투명해져 있다. 만일 더욱 복잡한 연산을 위하여 intermediate 버퍼와 분리된 컴포짓팅을 통하여 원하는 바대로 렌더링 할 수 있다.
  

 

 

Coordinate transforms

• 손쉽게, BeginPlatformPaint가 호출될때마다 SkDevice는 Windows좌표 변환과 동기를 맞춘다. 이는 현재의 변환을 걱정하지 않고 GDI operation을 호출할 수 있는 것을 의미한다. ( 윈도우가 지원하지 않는 Perspective transform 셋업을 제외하고)

• 하지만, 이것은 결국 변하게 되어있다.