在玩ff14的时候中文模式按字母键狂掉帧数

[MoonSueAoi]

按wasd或者其他的会导致帧数下降，狂按直接降到1帧了

[oTnTh]

我这里没有复现你说的问题。

按enter焦点移动到聊天框，切到中文打几个字，然后按ESC，再用asdw移动，帧率没有变化，任务管理器里gpu占用也没有特别大的起伏。

你把能退出的程序都退出了试试。

[CDHJS]

在任何程序都会有类似的情况，我是使用的雾凇拼音，只要打字就会造成主进程卡顿，这是tsf的原理引起的
下图为Minecraft 1.20.5的F3+2，可以很清楚的看到在打字时会阻塞主进程并降低帧数，按住时直接卡死，点按阻塞时长逐步上升
一个可能的修复方法是用多线程/进程把耗时任务放到其它进程避免阻塞主进程/使用简单快速的输入方案/关闭输入法
看#1159 的情况可能是Windows的锅，在不该启动输入法的情况下启动了输入法
微软拼音也有类似的问题，但因为速度快所以帧数影响较小，并且有上限

[oTnTh]

这个是MC内置的工具么，我刚才又去ff14里试了一下，在任务管理器里看CPU占用，还是没有观察到明显的变化。

Windows现在输入法的工作模式跟以前不一样了，rime没办法也只能跟着变。

目前小狼毫还可以做到“关闭输入法”这件事，但要是跟着微软拼音的实现走的话，以后可能小狼毫也会拿掉这个功能。

如果输入法影响游戏性能这个问题确实存在的话，我觉得还是有找一找问题所在的必要。

比如说是不是方案占用了太多资源，或者能不能定位到究竟是哪个部分占用了过多资源之类的。

[fxliang]

猜测可能是目前默认的状态，小狼毫输入法的按键都要IPC传递给服务，等回复。如果在/toggleime状态的时候关闭了输入法，那响应就应该是正常的。

[CDHJS]

这个是MC内置的工具么，我刚才又去ff14里试了一下，在任务管理器里看CPU占用，还是没有观察到明显的变化。

Windows现在输入法的工作模式跟以前不一样了，rime没办法也只能跟着变。

目前小狼毫还可以做到“关闭输入法”这件事，但要是跟着微软拼音的实现走的话，以后可能小狼毫也会拿掉这个功能。

如果输入法影响游戏性能这个问题确实存在的话，我觉得还是有找一找问题所在的必要。

比如说是不是方案占用了太多资源，或者能不能定位到究竟是哪个部分占用了过多资源之类的。

CPU并不会有较高的占用，是直接卡死主进程的
尝试了下原神，在输入框按住某个键也是直接卡死整个进程，但在正常游戏中按键并不会给TSF接收到
Firefox按住也是卡死主进程，但渲染正常，可以观测到的是按住时视频正常播放但不缓冲了，所以我说在任何程序都会有类似的情况

[CDHJS]

猜测可能是目前默认的状态，小狼毫输入法的按键都要IPC传递给服务，等回复。如果在/toggleime状态的时候关闭了输入法，那响应就应该是正常的。

有没有可能把UI分离出来，在组词时不需要等回复，只有选词插入时才通过IPC取词，这个功能感觉在预编辑区内容非候选时是成立的

[fxliang]

首先ui怎么个分出来，目前没有办法分离
如果怀疑是ui性能不够，可以将style/layout/margin_x设置为负值隐藏输入框看有没有变化，如果没有变化那就不是ui性能的问题

其次，通信是全部按键事件都有在做的，至于是不是要更新ui是看内容变化情况而定的。

再次，如果后端的插件多响应慢或者方案复杂计算多，那肯定会影响前端的响应的

[CDHJS]

首先ui怎么个分出来，目前没有办法分离 如果怀疑是ui性能不够，可以将style/layout/margin_x设置为负值隐藏输入框看有没有变化，如果没有变化那就不是ui性能的问题

其次，通信是全部按键事件都有在做的，至于是不是要更新ui是看内容变化情况而定的。

再次，如果后端的插件多响应慢或者方案复杂计算多，那肯定会影响前端的响应的

不是怀疑UI性能不够，是为了让主进程不必等待组词并且UI可以“异步”更新，这样后端再慢也不影响主进程的帧率，只有选词的那一刻需要等待，UI分出来的思路是让服务来创建窗口，TSF只需要发送位置和按键而不必等待算法响应

[lotem]

遊戲裏需要輸入中文嗎？
不轉換（ascii_mode=true）時響應速度如何？

按照目前 librime 的處理流程，按鍵的處理結果和候選詞同時返回，分開不容易。
因爲有些按鍵處理的過程會用到轉換結果，處理完成，候選詞也已經算完。
框架這樣設計，流程比較統一，也考慮到，轉換算法本身應當做到足夠快，而不是試圖靠異步優化。
如果性能很差，是不是方案設置的規則太複雜或是使用了腳本程序？

UI 由前端繪製有必要，TSF 是這樣設計的。已經改成這樣很久了。可以翻查以往的記錄。

[CDHJS]

遊戲裏需要輸入中文嗎？ 不轉換（ascii_mode=true）時響應速度如何？

按照目前 librime 的處理流程，按鍵的處理結果和候選詞同時返回，分開不容易。 因爲有些按鍵處理的過程會用到轉換結果，處理完成，候選詞也已經算完。 框架這樣設計，流程比較統一，也考慮到，轉換算法本身應當做到足夠快，而不是試圖靠異步優化。 如果性能很差，是不是方案設置的規則太複雜或是使用了腳本程序？

UI 由前端繪製有必要，TSF 是這樣設計的。已經改成這樣很久了。可以翻查以往的記錄。

不转换时几乎不影响帧数，而且如果不是同一个按键按十几次以上的非正常输入也不会出现可见的卡顿，我只是提供了一个可能解决问题源头的思路，这个issue的问题主要还是在Windows，weasel如果要解决的话可以参照微软拼音给输入设置一个上限或者让用户自行切换输入法

[oTnTh]

我再去试了一下，感觉楼主说的，跟后面讨论的，可能不是一回事。

原神和FF14里，我都可以观察到CDHJS说的情况。

1、在游戏要求用户输入文本的地方，打开小狼毫的中文输入模式，按着一个键不放，确实能观察到游戏帧率狂掉。

2、完成中文输入后继续游戏，此时小狼毫仍然处于中文输入模式，按住ASDW进行操作，游戏帧率并没有发生变化。

操作1导致帧率下降，因为本来也不是打游戏时会出现的正常操作，所以我觉得是还好。

但是看描述，楼主说的是操作2时，会出现帧率下降的情况，可是在我这里没法复现。

如果是操作2会影响游戏帧率，那就确实是个问题。