图形学图像处理【免费下载链接】skiaSkia is a complete 2D graphic library for drawing Text, Geometries, and Images.项目地址https://gitcode.com/gh_mirrors/skia1/skia点击查看免费下载本指南以 infra/debugger-app/README.md 为骨架结合 infra/debugger-app/BUILD.bazel、infra/debugger-app/Makefile、bazel/skia_app_container.bzl 与 bazel/buildrc 等仓库源码系统讲解如何用 Bazel 将 CanvasKit 构建产物注入中间 Docker 镜像、生成最终镜像、在本地运行调试以及推送到 GCR 并部署到 debugger.skia.org 的完整链路。读完你将掌握make build、docker run、make push_debugger_I_am_really_sure等核心命令的底层原理与实战用法。一、背景Skia Debugger 应用的镜像构建模式Skia 官方在 debugger.skia.org 上托管了一个基于 Web 的 Skia Debugger 应用用于在浏览器中加载并调试 Skia 的绘制命令Skia Picture / SKP。该应用的 Web 前端依赖 Skia 仓库产出的 CanvasKit 构建产物WebAssembly 版本的 Skia。本文档描述的这个目录承载了为 debugger 应用构建最终 Docker 镜像的 Bazel 构建规则其核心设计是一个中间镜像debugger-app-base由 Skia 基础设施仓库buildbot 仓库的debugger-app/BUILD.bazel创建内含 debugger 应用本身的 Web 服务二进制与页面资源本仓库的构建规则负责把 Skia 仓库特有的CanvasKit 构建产物Wasm 二进制、版本文件、TypeScript 类型声明注入该中间镜像合并后的最终镜像被上传到 GCRGoogle Container Registry随后部署到 skia.org 域名下的 debugger.skia.org。这种应用外壳与图形库内核分离、跨仓库组装的模式保证了 debugger 前端可以独立演进而图形库内核始终与当前 Skia 源码保持同步。二、构建规则拆解BUILD.bazel 中的 skia_app_container最终镜像的组装逻辑全部集中在 infra/debugger-app/BUILD.bazelload(//bazel:skia_app_container.bzl, skia_app_container) # Modify the debugger-app container by injecting the artifacts from this # repository on which it depends. skia_app_container( name debugger_container, base_image debugger-app-base//image, dirs { /usr/local/share/debugger-app/: [ [ # This brings in all the build files. //modules/canvaskit:canvaskit, 0644, ], [ //modules/canvaskit:version.js, 0644, ], [ //modules/canvaskit:npm_build/types/index.d.ts, 0644, ], ], }, entrypoint /usr/local/bin/debugger-app, repository skia-public/debugger-app-final, )各参数含义如下参数值说明namedebugger_container规则名会派生生成push_debugger_container推送目标base_imagedebugger-app-base//image基础镜像来自外部仓库依赖见下文dirs见上容器内目录到文件的映射每个条目为[Bazel 目标标签, 文件权限]entrypoint/usr/local/bin/debugger-app容器启动入口由 buildbot 仓库的中间镜像提供repositoryskia-public/debugger-app-final推送到 GCR 时的仓库名最终地址为gcr.io/skia-public/debugger-app-finaldirs中注入的三类产物分别承担不同职责//modules/canvaskit:canvaskitCanvasKit 的 WebAssembly 构建产物含全部构建文件这是 debugger 在浏览器中实际执行 Skia 绘制的运行时核心//modules/canvaskit:version.jsCanvasKit 版本号脚本供前端页面展示与缓存失效控制使用//modules/canvaskit:npm_build/types/index.d.tsTypeScript 类型声明供 debugger 前端以类型安全的方式调用 CanvasKit API。它们都被放置在容器内的/usr/local/share/debugger-app/目录下权限为0644文件所有者可读写其余用户只读与镜像中其他 Web 静态资源共存。三、底层宏skia_app_container 的实现原理skia_app_container是仓库复用的通用容器构建宏定义在 bazel/skia_app_container.bzl 中bazel/目录下还配套有 BUILD.bazel 等基础设施。它基于rules_docker与rules_pkg按以下步骤生成镜像逐文件生成pkg_tar规则对dirs字典中的每个[Bazel label, mode]元组创建一个pkg_tar把对应产物以指定权限放进容器内的目标目录见宏源码 bazel/skia_app_container.bzl 中for dir in dirs循环。这些规则带有tags [manual]避免被bazel build //...之类的通配查询误触发container_image组装镜像以base_image为基础层叠加所有pkg_tar设置entrypoint与默认用户。默认用户为skia可通过default_user参数调整如skfe这类应用需要 root可选的container_run_and_commit若指定了run_commands_root/run_commands_skia宏会先在临时镜像里以对应用户执行 RUN 命令再提交为新镜像最后用container_image恢复entrypoint与默认用户。这些目标额外带no-remotetag因为container_run_and_commit需要本地 Docker daemon无法在 RBE远程构建执行环境运行生成push_name推送目标通过container_push把镜像推送到gcr.io下repository指定的仓库tag 使用{STABLE_DOCKER_TAG}由--workspace_status_command提供的工作区状态变量注入见下文 buildrc 部分。基础镜像的来源在 WORKSPACE.bazel 中声明约 L689-L695# Pulls the gcr.io/skia-public/debugger-app-base container. container_pull( name debugger-app-base, digest sha256:cf5bc2e4a408ae68ab199d65b1d7550be8ed1aaa57f97340598fc2df4e110ad6, registry gcr.io, repository skia-public/debugger-app-base, )即构建时按digest镜像摘要从gcr.io/skia-public/debugger-app-base拉取不可变版本确保可复现构建该镜像由 Skia 基础设施仓库buildbot中的debugger-app/BUILD.bazel产出其中包含 debugger 应用的 Web 服务二进制。四、本地构建make build 的实际执行链路README 给出手动构建本地镜像的方式make build该命令在 infra/debugger-app/Makefile 中的定义如下BAZEL?bazelisk .PHONY: build build: $(BAZEL) run //infra/debugger-app:debugger_container \ --configdebugger_app_container要点拆解BAZEL?bazelisk表示默认使用bazeliskBazel 版本管理器允许通过环境变量BAZEL覆盖为其他 Bazel 可执行文件bazel run //infra/debugger-app:debugger_container构建并加载容器镜像到本地 Docker daemon输出形如Loaded image ID: sha256:...与Tagging ... as bazel/infra/debugger-app:debugger_container的信息可参考 bazel/skia_app_container.bzl 文档注释中的示例输出--configdebugger_app_container是关键的构建配置定义于 bazel/buildrc# config when building //infra/debugger-app:debugger_container. # This is invoked in a Louhi flow. build:debugger_app_container --configck_full_webgl2_release_debugger \ --workspace_status_commandbazel/get_workspace_status.sh它进一步展开为build:ck_full_webgl2_release_debugger --configcanvaskit_full --configck_webgl2 \ --configrelease --configck_debugger即一次叠加四组配置完整含义为配置作用canvaskit_full启用全部编解码器gif/jpeg/png/webp 解码与 jpeg/png/webp 编码、HarfBuzz ICU 字体排版、自定义内嵌字体管理、CanvasKit 字体/SKP 序列化/Skottie/RuntimeEffect/Matrix 等 JS 特性并禁用 tracingck_webgl2启用 WebGL 后端并禁用 legacy shader contextGPU 渲染路径release--compilation_modeopt优化编译ck_debugger--enable_build_for_debugger专为 debugger 应用开启的构建开关见 bazel/buildrc 中build:ck_debugger定义同时--workspace_status_commandbazel/get_workspace_status.sh注入 git 版本等工作区状态供{STABLE_DOCKER_TAG}使用。五、本地运行与调试docker run 用法README 提供两种本地运行方式。正常启动服务将容器内 8000 端口映射到宿主机 8080docker run -p 8080:8000 -it image ID-p 8080:8000宿主机 8080 端口转发到容器 8000 端口之后在浏览器访问http://localhost:8080即可使用 debugger-it分配交互式 TTY便于观察日志输出。镜像 ID 来自上一步make build输出的Loaded image ID也可以使用 Bazel 赋予的镜像名如bazel/infra/debugger-app:debugger_container。进入容器 Shell 排查问题绕过 entrypointdocker run -it --entrypoint /bin/sh image ID--entrypoint /bin/sh会覆盖镜像中配置的/usr/local/bin/debugger-app启动入口直接进入交互式 Shell方便检查/usr/local/share/debugger-app/下 CanvasKit 产物是否就位、权限是否正确或手动启动服务进程进行排障。六、自动构建与手动推送CI/CD 流程README 说明该 Docker 镜像由 LouhiSkia 的持续集成流水线在代码提交后自动构建并推送到 GCR正常情况下无需人工干预。Louhi 流水线正是以--configdebugger_app_container调用与make build相同的 Bazel 目标。仅当确有手动推送需求时才使用以下命令目标名中的I_am_really_sure是刻意的安全提示提醒操作者这是面向生产 GCR 的推送动作make push_debugger_I_am_really_sure对应 infra/debugger-app/Makefile 中的定义# Review section in README.md before running this target .PHONY: push_debugger_I_am_really_sure push_debugger_I_am_really_sure: $(BAZEL) run //infra/debugger-app:push_debugger_container \ --configdebugger_app_container执行后宏生成的container_push目标会把镜像推送到gcr.io/skia-public/debugger-app-final:tag。container_push同样带manual与no-remotetags——前者避免被通配构建误执行后者是因为推送过程需要本地 Docker daemon 参与无法在 RBE 中完成。注意手动推送前请仔细阅读 infra/debugger-app/README.md 的说明并确认本地已具备访问gcr.io/skia-public的凭据。日常迭代请优先依赖 Louhi 自动流水线。七、延伸同类容器构建的对照参考debugger-app并非仓库中唯一采用skia_app_container的应用。在 bazel/buildrc 中可以看到同构的配置例如jsfiddle_container、shaders_container、skottie_container均以ck_full_webgl2_release或叠加 debugger 开关为基线配合--workspace_status_command构建各自的 Web 应用容器。若你负责维护这类应用镜像可将本文的构建链路Makefile → Bazel config → skia_app_container 宏 → container_pull 基础镜像作为通用参考模板只需替换dirs中注入的产物与repository名称。八、常见问题排查速查make build报错提示找不到debugger-app-base//image确认网络可访问gcr.io且已执行bazel fetch拉取外部依赖该镜像按 digest 锁定见 WORKSPACE.bazel内容变更需由 buildbot 仓库重新发布。bazel run卡在 RBE 相关报错container_run_and_commit与container_push目标带有no-remotetag需在本地执行、确保 Docker daemon 运行中。镜像内 CanvasKit 产物缺失通过docker run -it --entrypoint /bin/sh image ID进入容器检查/usr/local/share/debugger-app/目录下是否存在 canvaskit 构建文件、version.js与index.d.ts并核对文件权限是否为0644。端口映射不生效确认容器实际监听端口是 8000-p 8080:8000中的后半段这与 debugger 应用服务默认端口保持一致。以上全部命令与配置均以当前仓库实际内容为准可直接在本地复现make build→docker run的完整本地验证流程而生产环境的自动构建与推送则交给 Louhi 流水线完成。赞分享图形学图像处理【免费下载链接】skiaSkia is a complete 2D graphic library for drawing Text, Geometries, and Images.项目地址https://gitcode.com/gh_mirrors/skia1/skia点击查看免费下载相关推荐Skia Debugger 应用 Docker 镜像构建指南从 CanvasKit 到 debugger.skia.org 的交付链路Skia Debugger 应用 Docker 镜像构建指南从 CanvasKit 到 debugger.skia.org 的交付链路 本指南围绕 Skia图形学Skia 的 GCC Docker 构建镜像infra/gcc 镜像体系与 Bazel/GN 构建实践Skia 的 GCC Docker 构建镜像infra/gcc 镜像体系与 Bazel/GN 构建实践 导读 Skia 的日常构建默认以 Clang 为主但图形学Skia jsfiddle Docker 镜像构建指南从 CanvasKit Bazel 制品到 jsfiddle.skia.org 部署Skia jsfiddle Docker 镜像构建指南从 CanvasKit Bazel 制品到 jsfiddle.skia.org 部署 导读 本文基于 i图形学上一篇医疗对话数据集深度解析如何快速构建智能问诊系统下一篇MiniCPM-Llama3-V-2_5-GPTQ本地部署指南CPU/GPU/NPU全方案低至8GB显存即可运行创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考