实际上原神今年 TGA 应该能拿奖了

@MADAOoo 也可以试试 CrossOver 20 的试用版，据说是可以打开的，但是应用支持情况未知。

@Gandum Rosetta 2 不支持虚拟化。

@vk42 如果整个 Wine 都跑在 Rosetta 2 里的话，Wine 应用是跑在 Wine 里的，也会被一起翻译执行。

@axbx 可以雷电外接一个 6K 60Hz，然后 HDMI 2.0 外接一个 4K 60Hz

实际上按照 Nvidia 的同代 GFlops 与功耗的关系，我们会发现显卡和 CPU 是很不一样的，显卡的性能与功耗几乎是线性的，并且提升一倍性能所需要的 TDP 通常要小于一倍。

那么，将 Apple M1 拓展到 RTX 3090 的性能的话，所需要的功耗只有 120W，而如果按峰值算力 35686 计算，再加上 Rosetta 2 的 65%性能折损，Apple M1 拓展至达到 RTX 3090 的性能也只需要 220W 功耗。

恐怖吗？也没那么恐怖，因为每次制程提升，同样的 die 里就能放入原先两倍的晶体管，如 7 * 7=49，5 * 5=25，后者是前者的两倍。

我们以 GTX 1000 系的 14nm 为例，理论上来说，Apple M1 应该比它提升 8 倍能耗，但那就接近 320 了，Apple M1 没有那么强。

但是最近大家都乱标制程，所以这个计算不准确。我们再以 GTX 2000 系 12nm 为例，理论上来说，Apple M1 应该比它提升 6 倍能耗，即 240-280 是合理数值，Apple M1 抵达了这个目标。

拉胯的反而是 3000 系，在制程提升后，它预期要比 2000 系提升 2.5 - 3 倍能耗的，但却只提升了两倍，而 7nm 到 5nm 又是 *2 的提升，所以才显得 Apple M1 的能耗那么离谱。

好奇 Wine 能跑吗？
https://github.com/Gcenx/homebrew-wine
上面写了仅限 Intel，但是没有补充说明为什么不行。
这个版本的 Wine 是带 wine32on64 的，意味着如果它能 Rosetta 2，相当一部分 Windows 需求可以解决。

好奇 Wine 能跑吗？
https://github.com/Gcenx/homebrew-wine
上面写了仅限 Intel，但是没有补充说明为什么不行。
这个版本的 Wine 是带 wine32on64 的，意味着如果它能 Rosetta 2，相当一部分 Win 需求可以得到解决。

你还不如标 1w6，然后接刀到 1w5，整数以下不接刀

如果是直接复制流的话应该不会太慢啊，或者用 mkv 做容器？

作为 ASGI 用户，每次看到 WSGI 们纠结 Windows 就觉得有 Uvicorn 真好，Waitress 到现在连个 SSL 都不支持，Uvicorn 功能已经做到快和 Gunicorn 齐平了。

@catfan 我是说右划的时候看不到上一页的预览的问题。如果点击链接前顶栏是缩回去的，点击后又打开了，那么前后 webview 高度不一致会使得右划无预览。

希望可以滑条调整夜间模式的对比度。

另外一些菜单文字和图标的对比度在夜间模式下不统一。

以及，WebView 有右滑白屏的 Bug，是这样的：当上一页面离开时的 WebView 高度和当前的 WebView 高度不一致的时候，右滑会出现白屏，这里需要单独对这个 WebView 的 Bug 做调整。

还有一些界面交互上可以明显看得出想学 ios，但是却在许多小的地方是反直觉的，比如阅读模式下滑不能关闭，比如一个有 Grip 的设置栏不能上下滑等等。

另外基于私心，我比较希望地址栏编辑时可以左右拖拽滚动，并且拥有语法高亮。

滚轮不支持倾斜，需要配合侧键组合才能实现横向滚动。

async 的支持怎么样？

@abersheeran 但是也同样无法解决闭包不可靠的问题啊，你只能规定禁止 scope 深拷贝，并且规定禁止 scope["session"] = {}这样的操作。

@abersheeran 但是你的中间件需要调用内层的 Application，而 send 则是一层一层传递下去，直到最后一层 Application 才调用这个 callable 的，所以你不应该在中间件里直接执行这个 send，而是要把它传递到更深层的 ASGI Application 里：

```python
async def __call__(self, scope, receive, send):
session = {}
scope["session"] = session

await self.app(scope, receive, send)
```

这样一来，你就只能存一个 scope 的闭包：

```python
async def __call__(self, scope, receive, send):
session = {}
scope["session"] = session

async def send_wrapper(message):
# do something to store session
scope["session"]["saved"] = True # 这里的闭包是不可靠的
await send(message) # 但是这里是可靠的

await self.app(scope, receive, send_wrapper)
```

但是就像 ASGI 标准里描述的那样，Scope 是会被下一层 Application 复制的，这就使得内层如果真的复制了 Scope 的话，外层对 Scope 的闭包引用读取到的只会是脏数据。我仔细思考过了，觉得这里如果 ASGI 不做调整，ASGI 的实现也不保存 Application 栈的话（因为像 Django 的 Daphne 一样保存栈是很消耗资源的），这里应该是没有解决方案的。

可如果 ASGI 提供一个单例的上下文的话：


```python
async def __call__(self, scope, receive, send):
session = {}
scope["session"] = session # 把它存到一个请求期间的上下文变量，不一定是 Scope

async def send_wrapper(message, scope): # 这里接收一个请求期间的上下文变量，不一定是 Scope
# do something to store session
scope["session"]["saved"] = True # 这里就不是闭包而是普通地用参数了，所以是可靠的
await send(message) # 这里本来就是可靠的

await self.app(scope, receive, send_wrapper)
```

或者，如果修改 ASGI 的规定，使得 Scope 由一个 immutable 变为一个 mutable single instance 的话，任何一个地方都可以取到一个可靠的 Scope 的引用，也就不会存在复制的问题了。

@abersheeran 我试了一下，结果倒是挺遗憾的，Python 里的正则的性能与捕获组的数量是呈线性关系的，与捕获组之间的包含关系无关。所以，将树展开成正则组的操作应该是仅在树的同级节点的时候可以通过合并获得性能提升，超过同级的情况下就是 Python 的语言性能和正则引擎的执行效率之间的撕逼取舍了。

我个人不倾向于使用换语言的方式实现这个，因为你似乎还没完全榨干 Python 呢。

将上下文传入 receive 和 send 是有意义的，比如不然的话，你怎样使用纯 ASGI 中间件实现一个干净的 Session 呢？ Session 的读取发生在__call__期间，而存储和 cookie 的更新则发生在 send 期间，而这之间则需要一个上下文去保存 Session 中的信息吧。

以及好像跑题了，说回来的话，我注意到你的实现实际上是个巨大的正则树。那么这样的话，这个正则树是否可以合并为一个巨大的单一正则以实现更大的性能提升和更少的内存占用呢？