CDHJS

> 这个是MC内置的工具么，我刚才又去ff14里试了一下，在任务管理器里看CPU占用，还是没有观察到明显的变化。 > > Windows现在输入法的工作模式跟以前不一样了，rime没办法也只能跟着变。 > > 目前小狼毫还可以做到“关闭输入法”这件事，但要是跟着微软拼音的实现走的话，以后可能小狼毫也会拿掉这个功能。 > > 如果输入法影响游戏性能这个问题确实存在的话，我觉得还是有找一找问题所在的必要。 > > 比如说是不是方案占用了太多资源，或者能不能定位到究竟是哪个部分占用了过多资源之类的。 CPU并不会有较高的占用，是直接卡死主进程的 尝试了下原神，在输入框按住某个键也是直接卡死整个进程，但在正常游戏中按键并不会给TSF接收到 Firefox按住也是卡死主进程，但渲染正常，可以观测到的是按住时视频正常播放但不缓冲了，所以我说在任何程序都会有类似的情况

> 猜测可能是目前默认的状态，小狼毫输入法的按键都要IPC传递给服务，等回复。如果在/toggleime状态的时候关闭了输入法，那响应就应该是正常的。 有没有可能把UI分离出来，在组词时不需要等回复，只有选词插入时才通过IPC取词，这个功能感觉在预编辑区内容非候选时是成立的

> 首先ui怎么个分出来，目前没有办法分离 如果怀疑是ui性能不够，可以将style/layout/margin_x设置为负值隐藏输入框看有没有变化，如果没有变化那就不是ui性能的问题 > > 其次，通信是全部按键事件都有在做的，至于是不是要更新ui是看内容变化情况而定的。 > > 再次，如果后端的插件多响应慢或者方案复杂计算多，那肯定会影响前端的响应的 不是怀疑UI性能不够，是为了让主进程不必等待组词并且UI可以“异步”更新，这样后端再慢也不影响主进程的帧率，只有选词的那一刻需要等待，UI分出来的思路是让服务来创建窗口，TSF只需要发送位置和按键而不必等待算法响应

> 遊戲裏需要輸入中文嗎？ 不轉換（ascii_mode=true）時響應速度如何？ > > 按照目前 librime 的處理流程，按鍵的處理結果和候選詞同時返回，分開不容易。 因爲有些按鍵處理的過程會用到轉換結果，處理完成，候選詞也已經算完。 框架這樣設計，流程比較統一，也考慮到，轉換算法本身應當做到足夠快，而不是試圖靠異步優化。 如果性能很差，是不是方案設置的規則太複雜或是使用了腳本程序？ > > UI 由前端繪製有必要，TSF 是這樣設計的。已經改成這樣很久了。可以翻查以往的記錄。 不转换时几乎不影响帧数，而且如果不是同一个按键按十几次以上的非正常输入也不会出现可见的卡顿，我只是提供了一个可能解决问题源头的思路，这个issue的问题主要还是在Windows，weasel如果要解决的话可以参照微软拼音给输入设置一个上限或者让用户自行切换输入法