user-interface - 为什么剪辑被认为“开罗太慢”?
问题描述
我开始着手为 GTK3更新经典的 GNOME Clearlooks 主题(最初是 GTK2),它通过分叉过时的Clearlooks-Phenix项目。
我以前从未处理过任何 GTK3 主题,所以我提出了一些错误的假设,即 CSS 样式表的剪切规则与浏览器处理它们的方式是一致的。
其中一个假设导致我提交了一份错误报告,该报告已在回复中关闭:
是的,在 gtk3 中没有进行剪裁。开罗太慢了。
自 Windows 3.1 以来,2D 剪辑一直是加速图形的主要内容。Cairo 已经可以在可用时利用显示硬件加速,它的许多演示都显着地使用了此功能。
对我来说,剪辑似乎应该是当今现代硬件的基本基础,它应该是有效的免费的。在什么情况下可以认为它足够慢以选择性地或完全禁用它(GTK 元素的某些区域似乎被剪裁或透支,我不知道是哪个)?正如特别提到的那样,这对开罗来说是基本的东西吗?
解决方案
正如蒂姆·贝德(Timm Bäder)所写: 用将像素切成两半的东西进行剪辑很复杂。(例如:圆形比适合像素网格的矩形更复杂。)
当然,剪裁以便仅绘制整个像素可以加快速度,因为需要触摸的像素更少。但是,仅包含 20% 像素的剪辑路径意味着需要对像素的当前值进行一些插值。
简单示例:将像素涂成白色。pixel = white
当像素刚刚设置为白色时。但是当只绘制 20% 的像素时,你会得到类似 的东西pixel = white * 0.2 + pixel * 0.8
,这要复杂得多。
推荐阅读
- entity-framework - Entity Framework Core 迁移在创建时为空
- python - 如果 SFTPToS3Operator 已经拥有 AWS 权限,应该把什么作为 s3_conn_id?
- awk - 根据范围过滤行
- prolog - Prolog - 为什么以下代码会永远生成解决方案 X=root?
- powershell - PowerShell CSV 脚本超时
- java - 为什么 ObjectMapper 将 Date 类型更改为 Long
- javascript - 打字稿中的增强抽象方法
- c - 是否有任何包装函数的 C 宏?
- reactjs - 反应我如何替换数据的价值
- assembly - 在 FASM 中调用 `_getch` 之前,无法弄清楚我必须将什么推入堆栈