Paint.NET 官方支持 Linux：借助 Wine 兼容层的跨平台新尝试

Paint.NET 迈出跨平台第一步

Paint.NET 是 Windows 平台上最受欢迎的免费图像编辑软件之一，凭借简洁直观的界面、强大的图层与滤镜功能，成为介于系统自带画图工具与 Photoshop 之间的理想选择。这款软件最初由华盛顿州立大学学生 Rick Brewster 于 2004 年作为毕业设计项目启动，最早基于 .NET Framework 1.0 和 GDI+ 构建。经过近二十年的持续迭代，Paint.NET 已迁移至 .NET 8（微软最新的跨平台运行时），但其渲染管线仍深度依赖 Windows 特有的 Direct2D 和 DirectWrite API，以及 WIC（Windows Imaging Component）等系统级组件。

Paint.NET 从 .NET Framework 1.0 迁移到 .NET 8 的过程实际上反映了微软整个 .NET 平台近二十年的战略转型。.NET Framework 最初是仅限 Windows 的闭源运行时，而 2016 年微软推出的 .NET Core 则是一次彻底的架构重构——它开源、模块化、且从设计之初就考虑了跨平台运行能力，支持 Linux 和 macOS。2020 年起，微软将 .NET Core 与 .NET Framework 统一为 .NET 5，随后每年发布一个新版本。.NET 8 作为 2023 年发布的长期支持（LTS）版本，在 AOT（Ahead-of-Time）编译、性能优化和容器化部署等方面都有显著改进。理论上，基于 .NET 8 的应用具备跨平台运行的基础条件，但 Paint.NET 的情况特殊：其核心渲染逻辑绑定了大量 Windows 专有 API，这些 API 并不在 .NET 跨平台运行时的覆盖范围内，因此运行时的跨平台并不等于应用本身的跨平台。

具体而言，Direct2D 是微软在 Windows 7 时代引入的硬件加速 2D 图形 API，它构建在 Direct3D 之上，能够利用 GPU 进行高效的 2D 渲染操作，如抗锯齿、几何变换和透明度混合。DirectWrite 则是与之配套的高质量文本渲染引擎，支持 OpenType 高级排版特性和亚像素定位。WIC（Windows Imaging Component）是 Windows 的底层图像编解码框架，提供了对 JPEG、PNG、TIFF、WebP、HEIF 等格式的统一编解码接口，并支持色彩管理和元数据处理。Paint.NET 将这三者深度集成到其渲染管线中：画布绘制依赖 Direct2D 实现 GPU 加速，文字工具通过 DirectWrite 获得高质量字体渲染，而图像的加载、保存和格式转换则由 WIC 统一处理。这种紧密耦合使得 Paint.NET 在 Windows 上能够充分利用系统级优化，但也意味着在非 Windows 平台上，每一个组件都需要找到对应的替代实现或兼容层。

这种架构选择赋予了它在 Windows 上出色的性能表现——尤其是 GPU 加速渲染和高效的内存管理——但也构成了跨平台移植的核心障碍。正因如此，Linux 用户长期以来只能通过各种非官方手段勉强运行，官方从未给出正式支持。

如今情况发生了变化。Paint.NET 官方宣布加入实验性的 Wine/Linux 支持，开发团队开始正视跨平台用户需求，并主动为 Linux 环境下的运行提供更好的兼容性保障。尽管目前仍处于早期阶段，但这一动作本身释放了重要信号。

为什么选择 Wine 而非原生移植

技术路线的现实考量

Paint.NET 基于 Microsoft .NET 平台构建，深度依赖 Windows 图形栈与相关 API。若要开发真正的原生 Linux 版本，团队需要重写大量与操作系统紧密耦合的底层代码，工作量巨大且后续维护成本高昂。对于一个小团队维护的项目而言，这几乎不现实。

相比之下，借助 Wine 是投入产出比更高的路径。Wine（递归缩写 Wine Is Not an Emulator）并非传统意义上的模拟器或虚拟机，而是通过在 Linux 内核之上重新实现 Windows API 调用来工作。Wine 的工作原理常被误解为「在 Linux 上模拟一个 Windows 环境」，但实际上它的机制更接近于 API 级别的实时转译。当一个 Windows 可执行文件（PE 格式）在 Wine 中启动时，Wine 的加载器直接将其映射到 Linux 进程空间中运行。应用中的每一次 Windows API 调用——无论是文件操作（kernel32.dll）、图形渲染（gdi32.dll、d3d11.dll）还是窗口管理（user32.dll）——都会被 Wine 实现的同名 DLL 拦截，并转译为对应的 Linux 系统调用或库函数调用。例如，CreateFile 被转译为 open()，窗口创建操作被转译为 X11 协议的窗口请求。由于没有指令级别的模拟或虚拟化，应用代码直接在宿主 CPU 上执行，理论上可以达到与原生运行几乎相同的 CPU 性能。图形方面的性能损耗主要来自 DirectX 到 Vulkan/OpenGL 的转译开销，但随着 DXVK 等项目的成熟，这种开销已经被压缩到了通常不超过 5-10% 的范围。

Wine 项目始于 1993 年，经过三十多年的持续开发，已实现了数万个 Windows API 函数的兼容。其子项目如 DXVK（将 DirectX 调用转译为 Vulkan）和 vkd3d-proton（DirectX 12 到 Vulkan 的转译）进一步扩展了图形兼容能力。DXVK 由独立开发者 Philip Rebohle 于 2017 年发起，它将 DirectX 9/10/11 的图形调用实时转译为 Vulkan API 调用。Vulkan 是 Khronos Group 维护的跨平台低级图形 API，在 Linux 上通过 Mesa 驱动栈得到所有主流 GPU 厂商的支持。DXVK 的出现彻底改变了 Wine 下 3D 应用的性能表现——此前 Wine 自带的 OpenGL 转译层在许多场景下性能损失严重，而 DXVK 利用 Vulkan 的低开销特性，在部分场景下甚至能超越 Windows 原生 DirectX 的性能。vkd3d-proton 则是 Valve 基于 Wine 项目的 vkd3d 库进行大幅改进的分支，专门处理 DirectX 12 到 Vulkan 的转译，支持光线追踪、网格着色器等现代 GPU 特性。对 Paint.NET 而言，其 Direct2D 渲染管线建立在 Direct3D 之上，理论上可以通过这些转译层在 Linux 上获得 GPU 加速支持。

借助这一成熟的兼容层，开发者无需重写核心逻辑，只需针对 Wine 环境中出现的兼容性问题进行适配与优化，就能让 Paint.NET 在 Linux 上稳定运行。

官方适配 Wine 的技术实践

Paint.NET 选择的「官方适配 Wine」模式与此前多数应用的做法有本质区别。传统上，Wine 兼容性主要依赖 Wine 社区和用户自行调试解决，应用开发者通常不会主动考虑 Wine 环境。而官方适配意味着开发团队会在持续集成（CI）流程中加入 Wine 环境测试，主动规避已知的 Wine 不兼容 API 调用，并在版本发布前验证关键功能路径。

将 Wine 环境纳入持续集成流程是官方适配的技术基础。在现代软件开发中，CI 系统（如 GitHub Actions、GitLab CI、Azure DevOps）会在每次代码提交后自动执行编译、测试和验证流程。对于 Wine 适配，这意味着开发团队需要在 CI 管线中配置 Linux 运行器，安装特定版本的 Wine 及其依赖（包括 32 位库、字体、图形驱动等），然后在该环境中自动运行应用的功能测试套件。这种做法能够在开发早期发现回归问题——例如某次代码更新引入了一个 Wine 尚未实现的 API 调用，CI 测试会立即报告失败。此外，团队还可以维护一份 Wine 兼容性清单，记录已知不兼容的 API 并在代码中提供替代路径。CodeWeavers 公司（Wine 项目的主要商业赞助商和代码贡献者）长期为企业客户提供类似的适配服务，其积累的经验表明，约 80% 的兼容性问题可以通过应用侧的少量代码调整解决，而无需等待 Wine 本身修复。

这种模式已有先例：Blizzard 的 Battle.net 客户端和部分游戏曾暗中测试 Wine 兼容性；一些企业级软件也长期与 CodeWeavers 的商业 Wine 发行版 CrossOver 合作优化兼容性。Paint.NET 的公开表态则更进一步，将 Wine 支持作为官方认可的运行方式纳入项目范围，这种透明度和承诺在桌面应用领域尚属少见。

实验性标签意味着什么

官方将当前支持标注为「实验性」，这意味着现阶段可能存在部分功能缺失、渲染异常或性能波动等问题。它更像是一次官方背书的兼容性尝试，而非承诺完整可用的 Linux 版本。对普通用户来说，可以尝鲜体验，但暂不建议用于生产环境。

对 Linux 桌面生态的实际意义

近年来，Valve 通过 Steam Deck 与 Proton 大力推动 Windows 游戏在 Linux 上运行，Wine 兼容层的成熟度与知名度显著提升。Valve 于 2018 年推出的 Proton 是基于 Wine 的定制化兼容层，专为 Steam 平台游戏优化，整合了 DXVK、vkd3d-proton、Wine-Staging 补丁集以及 Valve 自研的多项技术改进，使得超过一万款 Windows 游戏能够在 Linux 上直接运行。2022 年 Steam Deck 掌机的发布更是将这一技术推向了消费者市场的前沿——这款搭载 Arch Linux 定制系统（SteamOS 3.0）的掌机需要依赖 Proton 运行绝大多数 Steam 游戏库内容。Valve 为此投入了大量工程资源回馈上游 Wine 项目和 Mesa 显卡驱动，带动了整个 Linux 图形栈的质量飞跃，使得 Wine 兼容层的可靠性和覆盖范围达到了前所未有的水平。越来越多的桌面应用开发者因此意识到，Wine 已经足够可靠，可以作为触达 Linux 用户的现实通道。

Paint.NET 的这一举措正是这股趋势的缩影，它反映出一个关键事实：软件厂商不必投入巨资做原生移植，也能以较低成本正式支持 Linux 平台。

对于长期缺乏优质图像编辑工具选择的 Linux 桌面用户而言，这是一个利好消息。Linux 桌面上的图像编辑工具生态已相当丰富但呈现两极分化。GIMP（GNU Image Manipulation Program）作为最知名的开源图像编辑器，自 1996 年首次发布以来一直提供了接近 Photoshop 级别的功能集，包括高级图层管理、Python-Fu 和 Script-Fu 脚本扩展、以及 GEGL（Generic Graphics Library）图形处理框架带来的非破坏性编辑能力，但其界面设计长期受到「学习曲线陡峭」的批评。2023 年发布的 GIMP 2.99 开发版展示了向 3.0 大版本过渡的方向，包括全面的 GTK3 界面重写和改进的色彩管理。Krita 由 KDE 社区维护，最初是 KOffice 套件中的图像编辑组件，后来重新定位为专业数字绘画工具，在画笔引擎、动画制作和 HDR 绘画方面投入了大量开发资源，并获得了多轮 Kickstarter 众筹支持，近年来也不断增强照片编辑能力。轻量级选择方面，Pinta 的历史值得特别说明——它于 2010 年由 Jonathan Pobst 启动，明确以 Paint.NET 为蓝本用 GTK# 和 Mono（.NET 的早期开源实现）重写，但由于维护者变更和开发资源不足，功能覆盖度始终不及 Paint.NET 原版。Drawing 等工具虽然也存在，但打磨程度与 Paint.NET 仍有差距。此外，darktable 和 RawTherapee 在 RAW 照片处理领域有着强大表现，但它们专注于摄影后期工作流而非通用图像编辑。

Paint.NET 恰好占据了「比基础画图工具强大、比 GIMP 简单易用」的中间生态位，这一定位在 Linux 平台上确实存在明显空缺。多样化的工具选择始终能让不同需求的用户受益，Paint.NET 轻量、易上手的特点，恰好填补了 Linux 平台上轻量级图像编辑工具的这个空白。

当前限制与未来前景

目前这条消息尚未引发广泛关注，一方面因为它仍处于实验阶段，另一方面 Linux 用户群体对图像编辑工具已有成熟替代方案。

不过从长远看，Paint.NET 官方态度的转变值得肯定。如果实验性支持能够逐步稳定，并通过社区反馈持续改进，它有望成为 Linux 平台上又一款值得推荐的轻量级图像编辑工具。对于希望在 Linux 上使用熟悉的 Windows 软件的用户来说，这种「官方适配 + Wine 兼容层」的模式，很可能成为越来越多桌面应用的标准跨平台方案。

随着 Wine 本身持续进化、Wayland 显示协议的普及带来更好的图形兼容性，以及 Valve 等行业巨头对 Linux 图形栈的持续投资，这种模式的可行性只会越来越高。Wayland 作为替代已有三十多年历史的 X11 窗口系统的新一代 Linux 显示协议，采用合成器直接管理显示输出的设计，消除了 X11 中大量冗余的协议往返，带来了更低的输入延迟、更好的安全隔离和原生的 HiDPI 支持。截至 2024 年，Ubuntu、Fedora、GNOME 和 KDE 等主流发行版和桌面环境已默认使用 Wayland。然而，Wine 对 Wayland 的原生支持仍在开发中——Wine 9.0 引入了实验性的 Wayland 驱动，但目前大多数用户仍依赖 XWayland（在 Wayland 会话中运行的 X11 兼容层）来运行 Wine 应用，这引入了额外的间接层，可能导致某些窗口管理行为和输入处理出现异常。Wine 项目正在积极开发原生 Wayland 后端，一旦成熟，将能直接利用 Wayland 合成器的能力，为 Paint.NET 等应用提供更流畅的窗口管理和更精确的输入响应。

总结

Paint.NET 的 Wine/Linux 实验性支持虽是一小步，却体现了跨平台策略的务实思路。它没有追求成本高昂的原生重写，而是选择拥抱日益成熟的 Wine 兼容层技术。对开发者而言，这是一种低风险的市场拓展方式；对 Linux 用户而言，则多了一个熟悉且值得期待的图像编辑选择。能否从「实验性」走向「正式支持」，仍取决于后续的兼容性打磨与社区反馈推动。

核心要点

• Paint.NET 官方宣布实验性 Wine/Linux 支持：开发团队主动为 Linux 环境下的运行提供兼容性保障，标志着这款 Windows 经典图像编辑器正式迈出跨平台第一步
• 选择 Wine 而非原生移植是务实之举：Paint.NET 深度依赖 Direct2D、DirectWrite、WIC 等 Windows 专有图形 API，原生 Linux 移植意味着重写大量底层代码；Wine 的 API 级转译机制允许应用以接近原生的性能直接运行，配合 DXVK 等图形转译项目，开发团队只需进行适配优化即可
• 官方适配模式开创先例：不同于以往依赖社区自行解决的 Wine 兼容性，Paint.NET 将 Wine 测试纳入 CI 流程、主动规避不兼容 API，这种透明度和承诺在桌面应用领域尚属少见
• Valve 生态推动 Wine 成熟度飞跃：Steam Deck 和 Proton 的成功使超过一万款 Windows 游戏在 Linux 上运行，Valve 对 Wine 和 Mesa 的持续投资带动整个 Linux 图形栈质量提升，为桌面应用借助 Wine 跨平台奠定了基础
• 填补 Linux 轻量级图像编辑空缺：Linux 平台图像编辑工具呈两极分化，GIMP 功能强大但学习曲线陡峭，Pinta 等轻量工具打磨不足，Paint.NET「比画图强大、比 GIMP 易用」的定位恰好补上中间空白
• 实验性标签意味着谨慎期待：当前阶段可能存在功能缺失和渲染异常，适合尝鲜但不宜用于生产环境；长期前景取决于 Wine 原生 Wayland 支持的成熟度和社区反馈驱动的持续改进