[Topic DIscussion] 活到老,学到老,今天学习deepin现在所用DCI图标格式。求解答。
Tofloor
poster avatar
buyike
deepin
Solutions Team Moderator
2025-07-09 21:03
Author

原因起源于:https://bbs.deepin.org.cn/post/288947

7楼官方表示:现在25的系统自带应用图标都已经换成了DCI格式,svg 的渲染会比较费内存,所以会引起桌面卡顿问题。

因为没有了解过,问了AI还闹了笑话,后面又问了另一个AI,好像这个AI没理解错误,但不知所讲是否准确,不知坛里有没大神,能够教下我。

对了,这里是deepin官方文档的解释:https://docs.deepin.org/linuxdeepin/master/dtkcore/dci.html


选择系统图标时,SVG图标通常是更通用、更强大且更推荐的选择。虽然“DCI图标”不是一个标准的行业术语,但我理解你可能指的是“基于设备上下文或分辨率动态调整的图标”或类似概念(有时也称为“响应式图标”)。让我们来详细比较一下:

📐 1. SVG图标 (Scalable Vector Graphics)

  • 优点:
    • 无限缩放: 基于矢量,可以在任何尺寸下保持完美清晰度,无论在高清视网膜屏还是大屏显示器上。
    • 文件小巧: 通常比同等视觉质量的位图图标(如PNG、JPEG)文件小很多,尤其对于简单图标。
    • 可编程性与交互性: 可以通过CSS轻松改变颜色、添加悬停效果、过渡动画,甚至*进行更复杂的交互。
    • 可访问性: 支持内嵌文本描述(</code>, <code><desc></code>)和ARIA属性,对屏幕阅读器友好。</li> <li><strong>设计保真度:</strong> 线条清晰锐利,不受分辨率限制。</li> <li><strong>易于修改:</strong> 在代码编辑器或矢量图形软件中修改方便(如调整颜色、形状)。</li> <li><strong>现代Web标准:</strong> 是W3C标准,被所有现代浏览器完美支持,是构建响应式、现代化Web应用的基石。</li> <li><strong>SEO友好:</strong> 文本内容可以被搜索引擎索引(如果是内嵌文本而非纯路径)。</li> </ul> </li> <li><strong>缺点:</strong> <ul> <li><strong>复杂图形性能:</strong> 包含大量复杂路径或渐变的高细节SVG可能比简单位图渲染更慢(但系统图标通常很简单,此问题不突出)。</li> <li><strong>学习曲线:</strong> 需要理解SVG DOM结构或矢量编辑工具才能高效创建和修改。</li> <li><strong>跨浏览器一致性:</strong> 极少数情况下,非常复杂的SVG特性在不同浏览器中可能有微小渲染差异(系统图标通常避免复杂特性)。</li> </ul> </li> </ul> <h2 id="--2---DCI图标----响应式-上下文感知图标--假设含义-">📱 2. “DCI图标” / 响应式/上下文感知图标 (假设含义)</h2> <ul> <li><strong>核心概念:</strong> 根据设备类型、屏幕尺寸、分辨率、像素密度、甚至用户偏好等“设备上下文信息”,提供或切换到最合适的图标资源(可能是位图或矢量)。</li> <li><strong>可能的实现方式:</strong> <ul> <li><strong>位图方案:</strong> 提供不同尺寸(如16x16, 24x24, 32x32, 48x48)和不同分辨率(1x, 2x, 3x)的PNG/JPG图标集合,通过HTML的 <code>srcset</code>和 <code>sizes</code>属性或CSS媒体查询选择。</li> <li><strong>混合方案:</strong> 使用SVG作为基础,但在特定场景(如极小的尺寸)使用专门优化的位图替代。</li> <li><strong>SVG方案:</strong> 使用单个SVG文件,但利用CSS媒体查*根据上下文改变其样式(如显示/隐藏某些部分、改变颜色)。</li> </ul> </li> <li><strong>优点:</strong> <ul> <li><strong>极致优化潜力:</strong> 理论上可以为每种特定场景提供最精确优化的资源(尤其是针对复杂图标在特定小尺寸下的像素级控制)。</li> <li><strong>解决SVG小尺寸渲染问题:</strong> 在非常小的尺寸下,某些复杂SVG的细节可能模糊或粘连,此时专门绘制的位图可能更清晰(虽然现代渲染引擎已大幅改善此问题)。</li> </ul> </li> <li><strong>缺点:</strong> <ul> <li><strong>复杂性:</strong> 需要生成、管理和维护多套资源(不同尺寸/分辨率)。</li> <li><strong>HTTP请求:</strong> 使用多个位图文件会增加HTTP请求数量(虽然HTTP/2缓解了此问题,缓存也有效)。</li> <li><strong>文件总体积更大:</strong> 存储多套资源的总大小通常远大于单个SVG文件。</li> <li><strong>不够灵活:</strong> 改变颜色或样式通常需要提供不同颜色的整套位图资源。</li> <li><strong>可访问性和交互性:</strong> 位图本身不具备SVG的可编程性和丰富的可访问性支持(需额外工作)。</li> <li><strong>非矢量:</strong> 位图资源无法无限缩放,在新出现的高分辨率设备上可能显得模糊。</li> </ul> </li> </ul> <h2 id="--结论与建议-SVG是首选-DCI-响应式作为补充优化">🏆 结论与建议:SVG是首选,DCI/响应式作为补充优化</h2> <ol> <li><strong>首选SVG:</strong> 对于绝大多数系统图标场景,<strong>SVG是绝对的首选和现代最佳实践</strong>。它完美解决了响应式设计的核心需求(无限缩放),同时提供文件小、可编程、可访问性好等巨大优势。现代UI框架和设计系统(如Material Design, Apple’s SF Symbols)都强烈依赖SVG图标。</li> <li><strong>“DCI”/响应式理念仍有价值,但通常配合SVG使用:</strong> <ul> <li><strong>核心是SVG:</strong> 优先使用单个SVG图标。</li> <li><strong>利用SVG内置响应性:</strong> 使用CSS媒体查询改变SVG图标的尺寸、颜色或内部元素的显示/隐藏。</li> <li><strong>极端情况优化(位图后备):</strong> 仅在<strong>极少数</strong>情况下,当某个图标在<strong>特定极小尺寸</strong>下(例如小于16px)且SVG渲染效果确实不佳时,可以考虑使用 <code><picture></code>元素或CSS媒体查询为该特定断点提供一张专门优化过的位图(PNG)作为后备。但这应该是例外,而非规则。</li> <li><strong>利用 <code>srcset</code> for SVG (谨慎):</strong> 如果有<strong>截然不同设计</strong>的SVG版本(比如极简版用于小尺寸,详细版用于大尺寸),可以使用 <code>srcset</code>。但通常更推荐使用CSS切换单个SVG的样式。</li> </ul> </li> </ol> <h2 id="--简单对比表">📊 简单对比表</h2> <table> <thead> <tr> <th align="left">特性</th> <th align="left">SVG 图标</th> <th align="left">“DCI”/响应式图标 (主要指位图方案)</th> </tr> </thead> <tbody> <tr> <td align="left"><strong>缩放性</strong></td> <td align="left">⭐⭐⭐ 无限缩放,完美清晰</td> <td align="left">⚠️ 有限缩放,大尺寸或高分辨率下模糊</td> </tr> <tr> <td align="left"><strong>文件大小</strong></td> <td align="left">⭐⭐⭐ 通常非常小 (简单图标)</td> <td align="left">⚠️ 需要多套文件,总体积较大</td> </tr> <tr> <td align="left"><strong>HTTP请求</strong></td> <td align="left">⭐⭐⭐ 通常1个 (或内联)</td> <td align="left">⚠️ 可能需要多个请求 (不同分辨率/尺寸)</td> </tr> <tr> <td align="left"><strong>颜色/样式修改</strong></td> <td align="left">⭐⭐⭐ 通过CSS轻松修改</td> <td align="left">❌ 困难,需提供多套资源</td> </tr> <tr> <td align="left"><strong>动画/交互</strong></td> <td align="left">⭐⭐⭐ 支持CSS/JS丰富动画和交互</td> <td align="left">⚠️ 有限支持 (通常需CSS Sprite或JS技巧)</td> </tr> <tr> <td align="left"><strong>可访问性</strong></td> <td align="left">⭐⭐⭐ 原生支持好 (<code><title></code>, <code><desc></code>, ARIA)</td> <td align="left">⚠️ 依赖 <code>alt</code>文本,支持较弱</td> </tr> <tr> <td align="left"><strong>渲染性能</strong></td> <td align="left">⭐⭐ 通常很好 (简单图标)</td> <td align="left">⭐⭐ 通常很好 (位图解码快)</td> </tr> <tr> <td align="left"><strong>小尺寸清晰度</strong></td> <td align="left">⭐⭐ 现代浏览器下通常很好</td> <td align="left">⭐⭐⭐ 可像素级精确控制 (如果专门优化)</td> </tr> <tr> <td align="left"><strong>维护复杂度</strong></td> <td align="left">⭐ 单个文件,易于维护</td> <td align="left">⚠️ 需管理多套资源,复杂度高</td> </tr> <tr> <td align="left"><strong>浏览器支持</strong></td> <td align="left">⭐⭐⭐ 所有现代浏览器完美支持</td> <td align="left">⭐⭐⭐ 广泛支持 (位图是基础)</td> </tr> <tr> <td align="left"><strong>现代Web标准推荐</strong></td> <td align="left">⭐⭐⭐ 是核心标准</td> <td align="left">⚠️ 是解决历史问题的方案</td> </tr> </tbody> </table> <p><strong>总结:</strong> <strong>拥抱SVG作为系统图标的基础</strong>。它的矢量特性、灵活性、性能和可访问性优势使其成为现代Web和应用程序开发的标杆。将“DCI”或响应式的思想理解为<strong>在SVG的基础上,利用其自身可编程性和少量媒体查询进行优化</strong>,或者在极其罕见的情况下为极小尺寸的复杂图标提供像素级优化的位图后备。对于绝大多数系统图标需求,一个精心设计的SVG文件就足够了。🎯</p> </div>
Reply Favorite View the author
All Replies
2 / 2
To page
猫粮
deepin
2025-07-10 08:59
#21
fslong

占很大,你去看看deepin的svg图标,他妈的里面塞了个png,一个svg图标4m大小你敢信?

估计软件直接转的svg

Reply View the author
deepin-superuser
deepin
2025-07-10 09:55
#22
buyike

这和当年的PCD有点相似呀,也是通过‌预存多级分辨率‌实现了“一档多用途”,用户打开时需‌主动选择适配当前输出场景的分辨率层级‌,可惜这格式一直没发展起来。

image.png

差不多就是这个意思,但不只分辨率 还有各种状态

例如一个按钮 还可以保存 普通情况、被按下时、鼠标移上去时、禁用时等不同状态的图片

Reply View the author
buyike
deepin
Solutions Team Moderator
2025-07-10 10:20
#23
deepin-superuser

差不多就是这个意思,但不只分辨率 还有各种状态

例如一个按钮 还可以保存 普通情况、被按下时、鼠标移上去时、禁用时等不同状态的图片

明白了,基本上如后面AI所说,有的地方还是硬伤,而且有额外的学习成本。

具体的区别还得长期使用后才能体会到,只是这个只格式只有deepin在用,所以,只有deepin的开发人员才能说清。

Reply View the author
zccrs
deepin
2025-07-10 10:49
#24

开头有个地方需要纠正一下,svg的渲染并不耗费多少内存,主要是耗费cpu。

svg 的优点很明显:

  1. 图标文件小,因为它本质上不是图,而是应该一个描述图长什么样子的代码
  2. 可以无损缩放,就跟html网页内容一样,因为是代码,所以放大缩小都不会失真

但是缺点也有很多:

  1. svg标准复杂,比如Qt支持的是 SVG Tiny 1.2 版本(Qt6之前),有不少功能不支持,就会导致一些svg图标使用Qt渲染后会出现黑块、渲染错位等问题。在deepin 20时代,一直是用 librsvg 这个库来代替 Qt SVG,它支持 SVG 1.1 标准,大部分图标都没问题,不过这个库的性能比Qt SVG要差一些(也可能不是代码性能差,而是支持的功能比Qt的多,导致渲染了更多的内容,所以比Qt的慢)
  2. svg的渲染支持比较成熟的方案都是cpu渲染,包括QtSVG、librsvg,对于复杂的svg(不是肉眼辨别,而是看svg里都使用了什么节点,以及节点的数量)渲染时都会消耗不小的cpu资源。目前对svg支持最好的是浏览器,而且svg的标准也多少跟web方面有着深度的耦合,比如能在svg里嵌入js代码之类的事情,这对非浏览器的使用场景很不友好

svg比着位图(png之类)也不是完全碾压,前面一直在讲“渲染”,渲染svg就是指解析svg的代码,把svg图变成位图(是的,你没有听错,svg要显示出来,最终还是变成了各种像素,在这一点上跟位图没有区别),虽然可以不变成位图,而是每次刷新时都重新渲染svg,但是这样cpu肯定吃不消,所以往往会把svg缓存为位图

接下来说一说png等位图格式。

位图格式的优点是:

  1. 表达力强,可以存储任何的可视内容。所以svg里也支持嵌入位图,以弥补有些视觉效果无法用svg表示的情况
  2. 格式众多,应用的很成熟,生态也很丰富
  3. 往往有硬件加速的解码方式,加载位图(以图标资源这种大小来说)对cpu资源的消耗不大

位图格式的缺点:

  1. 分辨率越高,文件大小就越大,但是对于图标文件来说,相比svg,位图的图标主题包的大小的膨胀还是可以接受的
  2. 放大会失真,也就是大家常说的模糊,但是deepin里的位图图标都提供了很高的分辨率版本,理论上不会因为图标资源的问题导致模糊,如果有发现哪些地方的图标不清晰,那就是代码上的bug
  3. 相比svg难以加工,这方面的加工不是指被人类加工,而是指代码上的加工,比如 svg 图标,如果想更新图标里的文字的颜色,这会很容易,但是png的图就很难完美的做到。但是幸运的是,这类需求是明确且小范围的,比如根据“活动色”改变图标的背景色/前景色等。为了满足这样的需求,dci 格式提供了“图层”的概念,把一个图标分成多层,可以允许定义某层的填充颜色。svg在这方面虽然编辑方便,但是标准方面却比较混乱,svg自身不是专门服务于应用程序图标的,所以在图标层面的标准则是一些Linux桌面环境自己设计的(比如KDE),所以对于svg图来说,实现跟随高亮色变色并不比png图有优势

那么,deepin的dci格式是什么?要解决什么问题?

dci本质上是一个压缩包,简单理解的话,可以认为它是一个类似于zip/tar包的东西,dci里实际上放置的还是png、webp等格式的位图文件。dci把多个png图片文件打包为一个文件,并且在里面规定了如何解读这些png图片(比如哪个图片用在亮色主题下,哪个图片用在暗色主题下)。详细的规范说明可以看:https://desktopspec.org/unstable/%E5%9B%BE%E6%A0%87%E6%96%87%E4%BB%B6%E8%A7%84%E8%8C%83.html

dci解决的问题:

  1. svg标准复杂,设计师出的svg图标难以被完全还原,比如设计师喜欢在图标里加阴影效果,这对于使用cpu渲染svg来说是个灾难
  2. 图标(不是指应用图标,特指程序内的图标,比如控制中心里用到的 > 样式的图标)分发困难,因为图标往往需要响应鼠标的动作,比如 hover、鼠标点击,响应动作后图标要产生变化,在没有dci之前,往往是由设计师提供多个svg或png格式的图,程序员自己用代码判断、组合应该在什么状态下使用哪个图,这个过程容易导致程序员还原出的图标效果与设计师的设计不一致,而且代码也会显得很混乱
  3. 另外就是一些更高级的需求,比如“跟随活动色变色”、“动画图标(比如鼠标放上去后会动起来)”

另外就是关于主题里提到的桌面卡顿的问题了,这个问题和用svg图标还是dci图标没有直接的关系,可以理解为是桌面自身的bug,桌面、启动器这些程序,会同时支持svg、dci、png等常见的图标格式,所以这类问题发现了根源肯定会解决的。

Reply View the author
buyike
deepin
Solutions Team Moderator
2025-07-10 11:31
#25

感谢解惑,还有些问题请教。

1、支持的问题:svg图标渲染成黑色这个以前没遇到过,但在deepin系统中以前经常看到,就是现在也有,我前面也反应过的一些问题应该就是此类状况。但在打开复杂的SVG文件时经常遇到,特别是使用linux下的inkscape,但在WIN下使用Illustrator确较少出现此类问题,是不是就是因为linux支持的库的能力问题,有办法优化吗?其他的linux会出现同类问题吗?此外,不管是直接使用SVG还是打包的dci最后还得面对这个库的支持程度,这样说没错吧。

2、效率的问题:这种打包的方式在使用时是不是更方便呢?此外,两种方式选择下谁的呈现更快呢,有进行过比较吗?

Reply View the author
2 / 2
To page