Screen to GIF 工程实践手记：当“点一下就出图”开始失效时，你在和谁较劲？
你有没有过这样的时刻：
明明拖选好了窗口区域，导出后动图却总差那么几像素——按钮被切掉一半，代码行号跑到了画布外；
明明设了100ms帧间隔，播放起来却像老电影卡顿，关键操作步骤全糊成一团；
明明只是录个带阴影的UI弹窗，导出的GIF却像被水洗过，圆角变锯齿、渐变变色块，连文字都发虚……
这不是你的错。
这是 Screen to GIF 在悄悄提醒你：它不是魔法盒子，而是一套运行在Windows图形栈夹缝中的精密流水线——表面轻量，内里层层耦合；界面极简，参数暗藏权衡。一旦系统环境微变（DPI缩放切换、显卡驱动更新、后台进程抢占），那条本该安静流淌的数据链就会突然打结。
我们不讲“怎么打开软件”，也不列“十个你不知道的功能”。这篇文章要带你掀开它的外壳，看清三处最常崩断的齿轮：坐标怎么算偏了？时间怎么变慢了？颜色怎么丢光了？每一处，都对应一个真实发生过的、让开发者抓耳挠腮的现场问题。
录制框为什么总“差一点”？——别怪鼠标，怪DPI映射没对齐
先说一个反直觉的事实：你在屏幕上拖出来的那个蓝色方框，它所代表的坐标，很可能根本不是屏幕真正要捕获的位置。
为什么？因为 Windows 的 DPI 缩放，本质上是在“骗”应用程序：告诉它“你看到的是1920×1080”，但实际显存里画的是2880×1620（150%缩放）。Screen to GIF 若没主动识破这场“骗局”，就会用你拖出的逻辑坐标，直接去读物理显存——结果就是：你框住的是 Chrome 地址栏，它截到的却是任务栏上方10px的空白。
这个错位，在以下场景中尤为顽固：
- 4K显示器 + 125%/150%系统缩放
- 笔记本接4K扩展屏，主副屏DPI不同（如主屏100%，副屏150%）
- 使用旧版（v2.28之前）或禁用了DPI感知模式
它不报错，只默默偏移。你反复调整录制区域，像在调试一个永远无法对准的瞄准镜。
真正起作用的，是这行代码里的一个乘法
pRect->left = MulDiv(pRect->left, dpiX, USER_DEFAULT_SCREEN_DPI);这行看似简单的坐标换算，是 v2.32+ 版本的救命稻草。MulDiv(a,b,c)是 Windows API 提供的高精度整数除法，避免浮点误差。它的意思是：
“把你拖出来的逻辑坐标（比如(200,150)），乘以当前显示器的真实DPI（比如150），再除以基准DPI（96），得到真正的物理像素位置。”
所以，当你在150%缩放屏上拖出 (200,150) 的框，实际捕获的是：(200 × 150) ÷ 96 ≈ (312, 234)—— 这才是显卡真正读取的起点。
如果你用的是旧版本，或者手动关闭了Per-Monitor V2DPI感知（在高级设置里），这行换算就不会执行。你的录制框，永远活在“逻辑世界”里，而屏幕捕获，
