直接进专门的 youtube 下载网站，复制链接进去，他给你生成链接的那种

## 画每一片：

参考链接：
https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Compositing
https://stackoverflow.com/a/18387192/2244973

如果每一片形状的数量是有限的，或者形状是无规律的：
1. drawImage 画 mask(即描述形状的图片)
2. globalCompositeOperation = 'source-in'; 设置为只允许画在 mask 上
3. drawImage 画图片本体
注意调整画图的 src 位置和 dest 位置

如果每一片形状的数量是非常多且有规律的：
1. 画一个 path，作为形状
2. context.clip(); 设置为只能在范围内画
3. context.drawImage 画图片本体

## 变成一体
这个没什么特别的吧，判断组合然后依次画上去就行了
在松鼠标的时候，判断一下原图中周围的块是不是真的在旁边，如果在就用并查集连在一起。再拖动的时候，这个集合的块全部一起移动，松开的时候，全部判断新的组合

2 个

如果不精确要求时间的话，不重新编码，用 2L 的那个
如果要求精确时间，就需要重新编码，快不了

骑到 i 点下车的最小代价 cost[i] = min { cost[j] + 骑 j 车到 i 点的代价 }，j 从电量骑到 i 点的车里选，把每个点选择的 j 存下来最后反查

就是用文字作为 mask，在原图上画一张预先准备好的或者生成的有颜色图片。

nircmd 有 win move 、win center 、win max 等命令，应该能满足需求了，移动窗口，居中，最大最小化等

P 帧应该是依赖前一个 I 帧，B 帧依赖前后各一个 I 帧。记录好当前 I 帧和下一个 I 帧的位置，随便给你一帧就能找到这一帧依赖的所有帧了。
不过确实按照 1L 说的，想要知道下载量，只看播放量肯定不行啊，感觉想要真正解决问题还是从下载部分入手比较好。

https://twitter.com/gavkar/status/1329263147920756739

"I was waiting for this. Our display pipes are many years ahead of the industry & this is just 1 of that. From contrast to accessibility to color management many teams at Apple, including my display driver team, put so much effort to it. Glad to see it makes a difference."

要加规模肯定要设计大芯片啊，以前 ipad 用的芯片好多都是带 X 的新设计的芯片。苹果没有 CPU 间高速互联的经验，民用产品搞 numa 不太可能。

F2 F5 F6 F7 F8 F9 F10 F12 用得很多

去年 TGA 上死亡搁浅参加了一圈儿了，10 个提名，得了其中 2 个。今年肯定不能上了吧。

ARM 的影响最多最多到总线一级，和外围设备互联没啥关系，我觉得就是 M1 没有设计这么多 IO

@misdake 看错问题了，刚才以为是求最高位在第几位。
求位数的话，我想就不断乘以 10 判断还有没有小数。

对于正数，取以 10 为底的对数，比如 log10(0.05)=-1.30103，需要+2 才能大于 0，所以是小数点后第二位
用这种数学方法的话，不同的计算方式可能有误差，需要注意，0.3-0.2=0.09999999999999998

lz 的意思我觉得是先抛一个硬币决定乘和除，然后随机一个 1~2 之间的数字，用当前值乘或除(根据硬币)这个数。

1.
你看你的代码，你得到的结果似乎是“假设手上有一些重量不等的砝码，使用 2 个砝码来称重(不多不少，必须是 2 个)，可以称哪些重量”
而不是“假设手上有 N 个重量不等的砝码，可以称哪些重量”

2.
你碰到的重复计算的来源是：每一次想要扔掉一个元素的时候，都遍历整个集合
会出现“先扔掉 1 再扔掉 2”和“先扔掉 2 再扔掉 1”的两种调用，但谁先谁后在这道题中无所谓，重复计算了。
为了避免重复计算，应当舍弃掉这两种情况中的 1 种，如总是要求“扔掉的数字必须必上一次扔掉的数字更大”

我觉得可能的一种 145623 的运行顺序：(不保证正确)
第一个 console.log(1)的时候，发起了刷 buffer 的请求，输出 1 。接下来的 bcde 因为没赶上这次的输出，被压进了主线程的 buffer，等待下一次刷新。
worker 线程在跑的时候，1“正在”输出，刷新时 worker 线程的 buffer 里已经有 456 了，输出 456 。(猜测不同线程的刷新是轮询的，而不是优先盯着一个)
下次刷主线程 buffer 的时候，buffer 里有 23，输出 23 。


如果在 isMainThread 判断之前加上一句 console.log ，提前刷一下 console.log 的 buffer，输出的顺序应该就和你想象的一样了。感觉就是 buffer 相关的原因。