페이지

레이블이 Webkit인 게시물을 표시합니다. 모든 게시물 표시
레이블이 Webkit인 게시물을 표시합니다. 모든 게시물 표시

2018년 7월 28일 토요일

옛날 KHTML소스코드 찾기..

자유/오픈소스 만화를 그리다 보니, 별걸 다 찾게 된다. 가장 오래된 KHTML소스코드를 찾아봤는데, 의외로 찾기 어렵다. 많은 오픈소스 프로젝트가 git으로 전환되면서 그 이전에 cvs등으로 관리하던 저장소가 접근이 안되서 초기 코드를 찾기는 정말 어렵다.

특히,  KHTML은 kdelibs에 포함되어 있어서 KHTML이라는 키워드로 찾으면 절대 옛날 코드를 찾을 수 없다. 오래된 메일링 리스트 글을 힌트로 아래 코드를 찾게 되었다.
2000년 11월 25일 마지막 커밋이 있는 것으로 보아 현재 접근 가능한 가장 오래된 KHTML소스 코드 같다. 

위 메일링 리스트 글도 언제 사라질 지 모르니 일단, 여기에 복사를 해둔다.

List:       kfm-devel
Subject:    changes in KHTML
From:       Lars Knoll 
Date:       1999-08-16 9:14:35
[Download message RAW]

Hi,

as some of you might have noticed, I checked the rewrite of khtml I've
done in the last month into CVS. Since it's (very) far from being complete
and stable, I've checked it into a seperate branch in kdelibs. You can get
it by 'cvs co -r khtml_to_dom kdelibs/khtml'.

I've rewritten khtml, to use DOM Level1 (see http://www.w3.org) for it's
internal document representation. The reason is mainly, that this is
IMO the only way, to be able to add javascript support to khtml.

Many (most) things are still not working, so don't expect too much from
this version. 

I'll just give a short description of what I've done so far:



* Dom:

The dom corresponds to the HTML DOM Level1 as defined by the w3c. It's
still not complete (HTMLCollection is for example still missing), but
already in a pretty useable state. The DOM is implemented as classes using
automatic memory management (each class in the DOM holds a pointer to a
class implementing the functionality, the implementation uses reference
counting to know, when it's not needed anymore). This has the advantage of
preventing memory holes in for example the code implementing the
javascript interface. However, khtml does internally use the
implementations directly, for speed and efficiency reasons.
The core dom is imlemented in the dom_*, html dom in the html_* files.

I've added drawing functionality to the HTMLElements of the dom, so they
can render themselves directly into the widget. Only block level elements
draw themselves, the inline elements and text are rendered by the
surrounding block level element. This makes it easier (at all possible) to
implement bidirectional behaviour and aligned objects. The old
khtmlobjects are not used at all anymore, but I've kept them in CVS for
the moment, as I still want to reuse their code.

The DOM does by the way use exceptions and namespaces, so khtml uses them
too now.

* tokenizer:

The tokenizer didn't change too much, but instead of writing the tokenized
stream into a buffer, it does now pass every token directly to the parser.

* parser

I rewrote it, since the parsing of the Attributes _has_ to be done now in
the elements (through the DOM attributes can be set even after parsing for
example by a script). It's much shorter now, and I wan't to implement some
sort of DTD support there at some point.

* probably some more things I forgot...



I've added a short test program, since kbrowser isn't linked into the lib
at the moment. 

You can also have a look at the files DESIGN for some more information,
and at the TODO file for some infromation on what's already done/working
and what still needs to be done.

Comments, critics, flames anyone?

Cheers,
Lars



애플 홈페이지에서도 옛날 흔적을 찾을 수 있다.
https://opensource.apple.com/tarballs/WebCore/ 여기서 가장 오래된 tarball을 열어보면 KHTML자취를 쉽게 찾을 수 있다.

2013년 10월 3일 목요일

BlinkOn Conference

지난 주에 샌프란시스코 Google 사무실에서 열린 BlinkOn Conference에 참석했다. Google이 WebKit Project에서 나와 Blink라는 이름으로 Browser Engine을 개발하기 시작한 이후, 처음 열리는 Blink 개발자 모임이다. WebKit committer로서 Community가 둘로 나누어지는 것은 가슴 아픈 일이였다. 하지만, Apple과 Google이 추구하는 바가 다른 이상, 혁신을 위해 각자의 길을 갈 수 밖에 없는 현실을 지켜볼 수 밖에는 없었다.

여러 회사가 이미 WebKit에서 Chromium으로 옮겨갔다. Qt가 Chromium을 기반으로 웹엔진을 개발하겠다고 발표해서 WebKit Community가 좀 시끄러웠다. Google이 Apple보다는 개방적으로 프로젝트를 운영하기 때문에 이러한 현상은 계속될 것 같다. Google에는 Chromium 관련 내부 mailing list 조차 없다고 하니, 열린 개발 방식이 얼마나 무서운지 새삼 느낄 수 있었다. 이제 Chromium Project가 모든 것을 다 빨아들이고 있다. 여기 승선하지 못하면 왠지 뒤떨어진다는 느낌을 갖게 되는 것도 무리는 아닌 것 같다.

이번 Conference에서 소개된 Blink 현황과 기술적인 내용을 살펴보자.

먼저, Blink의 성능 향상과 위한 노력이 진행중이다. 성능은 Parsing, DOM, HTML, SVG, CSS 처리, Style resolution, Layout, Rendering 등등 전반적으로 모든 부분에서 개선 중이다. Blink내 Web Engine이 가져야할 핵심 기능이 아닌 Platform관련 코드 (예, keycode 변환), Networking(예, WebSocket Protocol), Rasterization 코드를 제거할 계획이다.

이외에 Chromium과 Blink의 모둘화 작업도 진행중이며, Blink와 V8의 garbage collection기능을 통합할 계획이다. Blink는 WebKit과 같이 Smart Pointer를 사용했는데, 이 부분이 모두 변경될 것 같다.
많은 시도들이 앞으로 일어날 예정이다.

Mobile과 관련된 Session이 하나 있었는데, Android Blink가 Desktop가 다른 점와 Mobile 환경의 여러 제약점, 빌드 방법 등을 소개하였다.
Android Blink는 platform코드 일부가 Java로 코딩되어 있어서 JNI로 Blink로 연결되어 있다. Mobile기기는 core개수, memory크기, GPU성능이 많이 뒤지지만 사용자는 초당 60FPS의 성능을 요구하기 때문에 여러가지로 어려운 상황이다. 프로세스를 많이 만들수도 없고 cache memory를 넉넉하게 사용할 수도 없다.  Network도 안정적이지 않고 비용이 든다. 그렇기 때문에, mobile은 특히 Chromium에게는 도전적인 부분이다. 이미 WebKit 기반의 Safari는 mobile에 많이 최적화되어 있지만, Chrome이 이제 시작 단계이다.

Performance 관련해서 Trace Event Profiling Tool이 소개되었는데, 아주 흥미로웠다. 툴을 이용해서 병목 지점을 찾고 code까지 고치는 것을 보여주었다. 특히, frame viewer를 이용해서 Skia paint를 단계별로 replay할 수 있는 기능까지 제공한다.

Rendering관련해서, 사실 Blink가 fork한 WebKit코드는 10년의 역사를 갖고 있고 계속 기능이 추가되다 보니 몇 개의 주요 class의 경우 코드 길이가 매우 길다.  RenderBlock이 6.8k, RenderBox가 4.7K이고 RenderLayer의 경우 HW 가속 및 svg관련 코드를 포함하고 있다.  또한 repaint도  불필요한 repaint를 줄이기 위해 최적화가 필요하다. 예로 table의 경우 여러번 다시 그리는 경우가 많다고 한다. 일부 웹사이트는 CSS 파일 크기도 커서 thread CSS parser를 도입할 필요가 있고, RenderStyle Cache 종류도 많고 복잡도가 높아서 개선이 필요하다고 한다.

Editing은 WebKit에서 독립하면서 maintainer가 없었는데, 이번에 새로 맡은신 분이 Editing 현황을 잘 소개해주었다. 연세가 지극하신 개발자인데, 유머있는 발표가 인상적이였다. 사실, WebKit/Blink의 모든 코드를 다 이해하는 사람은 없다. 특히, Editing부분 소수의 사람만이 이해하고 있는 다소 복잡다고 높고 버그가 많다고 알려져있지만, 발표자는 전혀 그렇지 않으니 많이 기여하라고 이야기해주었다. 재밌는 것은 Rich Edit 기능을 JS로 구현할수도 있다는 사실이다. Web Engine의 일부 기능을 JS로 구현하는 것은 성능이나 메모리 사용 때문에 주저할 수도 있겠지만, 복잡도가 높아서 Engine에서 분리할 수 있다면 나쁘지 않은 선택일 수도 있다.

Open Source 개발자에게 특히 외부 contributor에게는 뭔가 일할 부분을 찾는 것이 쉽지 않다. 그냥 보면 모두 완벽해 보이기 때문이다. 하지만 이런 자리에서 문제점을 확인하고 뭔가 기여할 만한 부분을 찾는 것은 굉장한 소득이다. 그리고, 내 patch를 review한 개발자와 만나 앞으로 개발 방향을 듣고 의견을 나누는 일도 좋았다.

여전히 웹은 진화 발전하고 있다. 이럼 흐름에 직접 기여할 수는 기회를 갖게 되어 기쁘다.

2012년 2월 20일 월요일

2012년 1,2월 브라우저 기술 동향

제13차 W3C HTML5 KIG(Korean Interest Group) 회의에서 발표한 최근 브라우저 기술 동향을 정리해보았습니다.
몇가지 특징을 살펴보면,
  1. Remote Debugging
  2. SPDY, SSL Faststart
  3. Hardware Accelerated Graphics
  4. V8
  5. Navigation Timing
  6. Large persistent cache
  7. requestAnimationFrame
  8. Preloading
  9. HTML5 APIs
HTML5 Feature를 살펴보면,
  1. AppCache
  2. FileSystem and File APIs (File, FileList, FileReader, Blob)
  3. localStorage for storing simple key-value pairs
  4. WebSQL for relational data (deprecated)
  5. IndexedDB
지원하는 Device API를 살펴보면,
  1. Geolocation API for accessing location
  2. HTML media capture for camera access
  3. Device orientation
  4. Android Intent URIs such as tel: and geo: that give access to the dialer and Google maps
FAQ 가운데, 중요한 것을 살펴보면,
  1. Is Chrome for Android Beta open source?
Android용 Chrome브라우저는 소스코드가 공개되어 있지만, 개발 브랜치는 공개되지 않았으므로, 아직까지 100% 오픈소스라고 말하기는 힘들 것 같습니다. 하지만 향후, Chromium Project를 통해 오픈소스화 될 것으로 예상합니다.
  1. Does Chrome for Android now support the embedded WebView for a hybrid native/web app?
아직은 지원하지 않지만, Chrome의 WebView를 쓸 수 있으면 독립 프로세스로 진정한 웹앱을 개발할 수 있을 것 같습니다.
  1. Does Chrome for Android support apps and extensions?
아직까지 계획에는 없다고 하지만, WebView를 쓸 수 있다면 앱은 가능할 것이고, 확장은 Desktop과 호환성을 갖추기는 어렵겠지만, 독자적으로 지원할 것으로 예상합니다.
  1. What version of Flash is supported on Chrome for Android?
Adobe도 이미 Mobile용 Flash를 지원하지 않기로 했기 때문에, 역시 Andrioid용 Chrome도 지원하지 않는다고 합니다.
  1. Is Canvas hardware accelerated?
Andorid가 사용하는 2D 그래픽 엔진인 Skia가 HW가속이 되므로, Canvas도 당연히 가속이 됩니다.
  1. What about WebGL support?
이 부분은 의외지만, 아직은 안된다고 합니다.
  1. Does Native Client work on Chrome for Android?
역시 지원하지 않습니다.
더 자세한 내용은 아래 원문을 참고하세요.
그외에,
Erisson에서 WebRTC Demo을 iOS에서 보여주었습니다. Erisson은 그동안 WebKitGtk+과 GStreamer를 기반으로 WebRTC를 구현했습니다. 이번에 iOS용 WebRTC App을 만들어서 서로 화상 통신하는 Demo를 보여준 것입니다. 참고로, WebRTC는 Chrome에서도 이미 구현을 해서 공개를 했고, Mozilla도 관심을 갖고 스펙을 만들고 있습니다. 향후, 웹에서 JS에서 사용가능한 WebRTC API 이용해서 쉽게 화상통신 기능을 구현할 수 있게 될 것입니다.
W3C에서 Shadow DOM이라는 스펙을 표준화하고 있습니다. 웹 UI를 구성하다 보면 자연스럽게 여러개의 구성요소로 화면을 나눌 수 있습니다. 사실 각각의 구성요소가 Widget이 되고 별개로 구분하여 재사용 가능할 수도 있습니다.  사실 HTML에서 사용하는 widget류의 element는 내부적으로 별도의 DOM 구조(Shadow DOM)를 갖고 있으나 접근이 막혀있습니다.   엘리먼트를 이용하면 DOM 구조의 경계를 넘나들 수 있게 됩니다. 그래서 CSS를 조정해서 보이는 모습을 변경할 수 있습니다. 테스트가 필요한 분은 이 글을 참고하세요.

마지막으로, Firefox10에 추가된 개발도구에도 관심을 가져주시기 바랍니다.
나머지 소식을 링크로 확인하세요.
  1. Reverse directions for CSS Animations are now available
  2. Apple has landed support for hardware accelerated CSS Filter animation.
  3. Decoding of JPEG images has been improved by 9% on Chromium.
  4. WebGL is now able to report errors to Web Inspector’s console.
  5. It is now possible to build Samsung’s WebKit EFL port with support for WebGL.
  6. Add a custom CSS Lexer for WebKit, doubling lexing performance!
참고
  1. http://peter.sh/2012/01/shadow-dom-pointer-lock-and-a-new-css-lexer/
  2. http://peter.sh/2012/02/mutation-observers-reversed-animations-and-faster-jpegs/

2010년 1월 18일 월요일

Rendering in WebKit



WebKit의  내부 동작을 설명해주는  video입니다. 구글에서 좋은 정보를 많이 공개하네요..

2007년 11월 20일 화요일

Safari 브라우저의 엔진, Webkit의 시작과 발전

iPhone출시와 더불어 Safari가 많은 관심을 받고 있습니다. 사실 Safari는 Apple에서 전부 개발한 것이 아니라 오픈소스 프로젝트인 KHTML 을 가져다가 만들었습니다. 참고로 KHTML은 KDE의 Konqueror 라는 브라우저에서 사용된 Layout 엔진입니다.

Apple은 2003년 처음 Mac OSX용 Safari를 출시하였고 2007년 들어 윈도용 Safari 베타 와 iPhone, iPod Touch용 Safari를 잇달아 출시하였습니다. Safari가 Open Source KHTML기반으로 개발되었기 때문에 Apple은 2005년 6월 브라우저 엔진만 WebKit 이라는 이름으로 공개하였습니다. Nokia도 WebKit 프로젝트에 동참하여 S60 Mobile Platform용 브라우저를 Webkit기반으로 개발하고 있습니다. 잠깐 가계도를 살펴보면,

KHTML -+---- WebKit (by Apple) --> Safari, Dashboard
|
+---S60WebKit --> Web Browser for S60 Mobile Platform (by NOKIA)
|
|----> Konqueror

Apple의 WebKit은 KHTML에 많은 수정을 가하여 현재는 fork하여 따로 소스코드를 운영되고 있습니다. S60Webkit은 Webkit 프로젝트에는 속해 있지만 역시 따로 소스코드를 운영하고 있습니다. Webkit에 반영된 추가 기능에 대해 일정 간격을 두고 S60Webkit에 반영하는 것 같습니다. 그동안 Nokia도 ARM기반으로 포팅하면서 Mobile Device에 최적화를 많이 했을 것입니다. Apple도 Nokia덕분에 iPhone에 쌩쌩 돌아가는 Safari를 쉽게 갖게 되었으리라 추측해봅니다.

하여간 두 회사가 오픈소스인 KHTML을 가져다가 서로 잘 활용하여 좋은 결과를 얻었습니다.



참고로 S60 Browser의 Architecture입니다. KHTML의 WebCore와 JavaScript Core를 포함하고 있습니다.

위 그림에서 Memory Manager는 Nokia에서 개발한 것으로 Nokia BSD 라이센스를 따르고 WebCore, JavaScript Core는 LGPL을 따르고 있습니다. 이 처럼 오픈소스를 가져다가 공개할 부분과 그렇지 않을 부분에 관해 명확히 구분하여 활용하고 있습니다. Memory Manager처럼 일부 Proprietary 모듈도 과감히 공개한 부분도 있습니다.

오픈소스를 활용한 좋은 예라고 할 수 있습니다.

현재, WebKit은 Mobile분야에서 각광을 받고 있습니다. 모토롤라의 리눅스 플랫폼에서도 Webkit을 사용하고 있으며 얼마전 발표한 구글의 모바일 플랫폼 Andrioid 역시 Webkit을 브라우저 엔진으로 채택하였습니다.

Mozilla도 내년에 Mobile Firefox를 출시를 준비하고 있습니다. 지금까지 WebKit이 다소 성능과 메모리 사용에 있어서 유리하다는 측면이 있었는데, Mobile Firefox는 성능과 함께 XUL기반 개발 환경도 지원하여 다양한 Add-ons와 Theme를 지원할 예정입니다.

두 브라우저의 선전을 기대해봅니다~