6. layer created when
It's the root object for the page
• It has explicit CSS position properties (relative, absolute or a
transform)
• It is transparent
• Has overflow, an alpha mask or reflection
• Has a CSS filter
• Corresponds to <canvas> element that has a 3D (WebGL) context or an
accelerated 2D context
• Corresponds to a <video> element
13年5月2日星期四
8. Rendering Path
from back layer to font layer
for each layer, start from the root renderObject ,
traversal down to the child object and stop at
object that belong to another layer
draw by using GraphicContext ,generating a bitmap
13年5月2日星期四
17. renderViewHost
// A RenderViewHost is responsible for creating and talking to a RenderView
// object in a child process. It exposes a high level API to users, for things
// like loading pages, adjusting the display and other browser functionality,
// which it translates into IPC messages sent over the IPC channel with the
// RenderView. It responds to all IPC messages sent by that RenderView and
// cracks them, calling a delegate object back with higher level types where
// possible.
//
// The intent of this interface is to provide a view-agnostic communication
// conduit with a renderer. This is so we can build HTML views not only as
// WebContents (see WebContents for an example) but also as views, etc.
13年5月2日星期四
18. RenderViewHostImpl(.h)
// This implements the RenderViewHost interface that is exposed to
// embedders of content, and adds things only visible to content.
//
// The exact API of this object needs to be more thoroughly designed. Right
// now it mimics what WebContentsImpl exposed, which is a fairly large API and
// may contain things that are not relevant to a common subset of views. See
// also the comment in render_view_host_delegate.h about the size and scope of
// the delegate API.
//
// Right now, the concept of page navigation (both top level and frame) exists
// in the WebContentsImpl still, so if you instantiate one of these elsewhere,
// you will not be able to traverse pages back and forward. We need to determine
// if we want to bring that and other functionality down into this object so it
// can be shared by others.
????????
13年5月2日星期四
19. RenderViewHostDelegate
//
// RenderViewHostDelegate
//
// An interface implemented by an object interested in knowing about the state
// of the RenderViewHost.
//
// This interface currently encompasses every type of message that was
// previously being sent by WebContents itself. Some of these notifications
// may not be relevant to all users of RenderViewHost and we should consider
// exposing a more generic Send function on RenderViewHost and a response
// listener here to serve that need.
13年5月2日星期四
20. RenderThread
// The RenderThreadImpl class represents a background thread where RenderView
// instances live. The RenderThread supports an API that is used by its
// consumer to talk indirectly to the RenderViews and supporting objects.
// Likewise, it provides an API for the RenderViews to talk back to the main
// process (i.e., their corresponding WebContentsImpl).
//
// Most of the communication occurs in the form of IPC messages. They are
// routed to the RenderThread according to the routing IDs of the messages.
// The routing IDs correspond to RenderView instances.
13年5月2日星期四
21. RenderView(Impl.h)
//
// RenderView is an object that manages a WebView object, and provides a
// communication interface with an embedding application process
//
13年5月2日星期四
22. IPC
a named pipe is created for each render process
for communication with the browser process
13年5月2日星期四
23. the render process
Each renderer has two threads ,The render thread is where the main objects such as the
RenderView and all WebKit code run. When it communicates to the browser, messages are
first sent to the main thread, which in turn dispatches the message to the browser process.
13年5月2日星期四
25. WebKit: Rendering engine.The Port is a part of WebKit that integrates
with platform dependent system services such as resource loading and
graphics.
• Glue: Converts WebKit types to Chromium types. This is our "WebKit
embedding layer." It is the basis of two browsers, Chromium, and
test_shell (which allows us to test WebKit).
• Renderer / Render host: This is Chromium's "multi-process
embedding layer." It proxies notifications and commands across the
process boundary.
• WebContents: A reusable component that is the main class of the
Content module. It's easily embeddable to allow multiprocess rendering
of HTML into a view.
• TabContentWrapper: Contains a single WebContents, and is the
connection point for all the additions ("TabHelpers") that Chrome
wants to keep in 1:1 relation with the WebContents.
• Browser: Represents the browser window, it contains multiple
TabContentsWrappers.
13年5月2日星期四
26. Chrome-specific code are provided in platform-specific
source files that live in platform/graphics/chromium.
13年5月2日星期四
33. content_shell_content_view
.so
content_shell_jni_
header
conent_shell_pak
content_shell_lib
.a
content_render
1
xxx
target name in gyp
./content
+port/browser
+public/browser
+browser
content_plugincontent_utility
content_worker
shell
depend
cotent_browser(.a) lots of ...(.a)
depend
link all the .a
check libcontent_shell_content_view.target.mk
search (OBJS) ,around line 201
$(obj).target = src/out/Debug/obj.target
your could rm the library then
make -j4 libwebkit
$(obj).target/third_party/WebKit/Source/WebKit/chromium/libwebkit.a
make libcontent_shell_content_view
13年5月2日星期四
38. Gesture handling
Recognizing use framework GestureDetector
and ScaleGestureDetector
handling in the native (CContentViewCore)
ContentViewGustureHandler
ContentViewGustureHandler.MotionEventDelegate
ZoomManager
13年5月2日星期四
