android_webview
apps
ash
base
blink
build
build_overrides
cc
chrome
chrome_elf
chromecast
chromeos
cloud_print
components
content
courgette
crypto
dbus
device
docs
accessibility
autofill
design
gpu
images
ios
media
memory
memory-infra
process
security
speed
sync
testing
ui
OWNERS
README.md
accessibility.md
adding_to_third_party.md
android_accessing_cpp_enums_in_java.md
android_build_instructions.md
android_cast_build_instructions.md
android_debugging_instructions.md
android_logging.md
android_studio.md
android_test_instructions.md
angle_in_chromium.md
atom.md
bitmap_pipeline.md
browser_view_resizer.md
building_old_revisions.md
callback.md
ccache_mac.md
chrome_os_logging.md
chrome_settings.md
chromedriver_status.md
chromeos_build_instructions.md
chromium_browser_vs_google_chrome.md
chromoting_android_hacking.md
cipd.md
cl_respect.md
clang.md
clang_format.md
clang_static_analyzer.md
clang_tidy.md
clang_tool_refactoring.md
closure_compilation.md
cocoa_tips_and_tricks.md
code_coverage.md
code_reviews.md
component_build.md
cr_respect.md
cr_user_manual.md
cygwin_dll_remapping_failure.md
debugging_with_crash_keys.md
documentation_best_practices.md
documentation_guidelines.md
eclipse.md
emacs.md
erc_irc.md
es6_chromium.md
fuchsia_build_instructions.md
fuchsia_sdk_updates.md
get_the_code.md
git_cookbook.md
git_tips.md
google_play_services.md
graphical_debugging_aid_chromium_views.md
gtk_vs_views_gtk.md
how_to_add_your_feature_flag.md
how_to_extend_layout_test_framework.md
installation_at_vmware.md
ios_build_instructions.md
ios_infra.md
ios_voiceover.md
ipc_fuzzer.md
jumbo.md
kiosk_mode.md
layout_tests_linux.md
linux_build_instructions.md
linux_build_instructions_prerequisites.md
linux_building_debug_gtk.md
linux_cast_build_instructions.md
linux_cert_management.md
linux_chromium_arm.md
linux_chromium_packages.md
linux_crash_dumping.md
linux_debugging.md
linux_debugging_gtk.md
linux_debugging_ssl.md
linux_dev_build_as_default_browser.md
linux_development.md
linux_eclipse_dev.md
linux_graphics_pipeline.md
linux_gtk_theme_integration.md
linux_hw_video_decode.md
linux_minidump_to_core.md
linux_password_storage.md
linux_pid_namespace_support.md
linux_plugins.md
linux_profiling.md
linux_proxy_config.md
linux_running_asan_tests.md
linux_sandbox_ipc.md
linux_sandboxing.md
linux_suid_sandbox.md
linux_suid_sandbox_development.md
linux_sysroot.md
linux_zygote.md
luci_migration_faq.md
mac_build_instructions.md
network_traffic_annotations.md
new_port_policy.md
old_chromoting_build_instructions.md
optimizing_web_uis.md
optional.md
origin_trials_integration.md
ozone_overview.md
piranha_plant.md
profiling_content_shell_on_android.md
proxy_auto_config.md
qtcreator.md
release_branch_guidance.md
retrieving_code_analysis_warnings.md
seccomp_sandbox_crash_dumping.md
servicification.md
static_initializers.md
sublime_ide.md
system_hardening_features.md
tab_helpers.md
task_scheduler_migration.md
test_descriptions.md
threading_and_tasks.md
tour_of_luci_ui.md
tpm_quick_ref.md
translation_screenshots.md
updating_clang.md
updating_clang_format_binaries.md
useful_urls.md
user_data_dir.md
user_handle_mapping.md
using_a_linux_chroot.md
using_build_runner.md
vanilla_msysgit_workflow.md
vscode.md
webui_explainer.md
webui_in_components.md
webview_policies.md
win_cross.md
win_order_files.md
windows_build_instructions.md
windows_split_dll.md
working_remotely_with_android.md
writing_clang_plugins.md
extensions
gin
google_apis
google_update
gpu
headless
infra
ios
ipc
jingle
mash
media
mojo
native_client_sdk
net
pdf
ppapi
printing
remoting
rlz
sandbox
services
skia
sql
storage
styleguide
testing
third_party
tools
ui
url
webrunner
.clang-format
.eslintrc.js
.git-blame-ignore-revs
.gitattributes
.gitignore
.gn
.vpython
AUTHORS
BUILD.gn
CODE_OF_CONDUCT.md
DEPS
ENG_REVIEW_OWNERS
LICENSE
LICENSE.chromium_os
OWNERS
PRESUBMIT.py
PRESUBMIT_test.py
PRESUBMIT_test_mocks.py
README.md
WATCHLISTS
codereview.settings

Initial migration of wiki content over to src/docs There will be a follow-up CL to ensure docs are following chromium’s style guide, links are fixed, etc. The file auditing was becoming too much for a single change and per Nico’s suggestion, it seems to be better to do + Bulk import with initial prune. + Follow-up CLs to clean up the documentation. So that each CL has its own purpose. BUG=none Review URL: https://codereview.chromium.org/1309473002 Cr-Commit-Position: refs/heads/master@{#345186}
62 lines
3.1 KiB
Markdown
62 lines
3.1 KiB
Markdown
# Bitmap Pipeline
|
|
|
|
This pages details how bitmaps are moved from the renderer to the screen.
|
|
|
|
The renderer can request two different operations from the browser:
|
|
* PaintRect: a bitmap to be painted at a given location on the screen
|
|
* Scroll: a horizontal or vertical scroll of the screen, and a bitmap to painted
|
|
|
|
Across all three platforms, shared memory is used to transport the bitmap from
|
|
the renderer to the browser. On Windows, a shared section is used. On Linux,
|
|
it's SysV shared memory and on the Mac we use POSIX shared memory.
|
|
|
|
Windows and Linux create shared memory in the renderer process. On Mac, since
|
|
the renderer is sandboxed, it cannot create shared memory segments and uses a
|
|
synchronous IPC to the browser to create them (ViewHostMsg\_AllocTransportDIB).
|
|
These shared memory segments are called TranportDIBs (device independent
|
|
bitmaps) in the code.
|
|
|
|
Transport DIBs are allocated on demand by the render\_process and cached
|
|
therein, in a two entry cache. The IPC messages to the browser contain a
|
|
TransportDIB::Id which names a transport DIB. In the case of Mac, since the
|
|
browser created them in the first place, it keeps a map of all allocated
|
|
transport DIBs in the RenderProcessHost. The ids on the wire are then the inode
|
|
numbers of the shared memory segments.
|
|
|
|
On Windows, the Id is the HANDLE value from the renderer process. On Linux the
|
|
id is the SysV key. Thus, on both Windows and Linux, the id is sufficient to map
|
|
the transport DIB, while on Mac is is not. This is why, on Mac, the browser
|
|
keeps handles to all the possible transport DIBs.
|
|
|
|
Each RenderProcessHost keeps a small cache of recently used transport DIBs. This
|
|
means that, when many paint operations are performed in succession, the same
|
|
shared memory should be reused (as long as it's large enough). Also, this shared
|
|
memory should remain mapped in both the renderer and browser process, reduci ng
|
|
the amount of VM churn.
|
|
|
|
The transport DIB caches in both the renderer and browser are flushed after some
|
|
period of inactivity, currently five seconds.
|
|
|
|
### Backing stores
|
|
|
|
Backing stores are browser side copies of the current RenderView bitmap. The
|
|
renderer sends paints to the browser to update small portions of the backing
|
|
store but, for performance reasons, when we want to repaint the whole thing
|
|
(i.e. because we switched tabs) we don't want to go to the renderer to redraw it
|
|
all.
|
|
|
|
On Windows and Mac, the backing store is kept in heap memory in the browser. On
|
|
Windows, we use one advantage which is that we can use Win32 calls to scroll
|
|
both the window and the backing store. This is faster than scrolling ourselves
|
|
and redrawing everything to the window.
|
|
|
|
On Mac, the backing store is a Skia bitmap and we do the scrolling ourselves.
|
|
|
|
On Linux, the backing store is kept on the X server. It's a large X pixmap and
|
|
we handle exposes by directing the X server to copy from this pixmap. This means
|
|
that we can repaint the window without sending any bitmaps to the X server. It
|
|
also means that we can perform optimised scrolling by directing the X server to
|
|
scroll the window and pixmap for us.
|
|
|
|
Having backing stores on the X server is a major win in the case of remote X.
|