碎碎念

想要切换到net8，但是touch的wpf直接切断了这条选择。

并且假设假设切换到了net8 native，那netfx几十kb体积小的优势就没了。这是唯一的缺憾。如果要保持兼容netfx，那一些api也利用不到还是会按照旧风格开发。

印象中的ErogeHelper是轻量和性能强劲的。自己的平板设备就一堆低性能，除了优化自己的实现以外，wpf的transparent大大的降低了动画的性能，还是感觉到非常卡顿。不知道动画实现能不能有优化的地点。但是期望avalonia能实现clickable transparent。假如wpf也能native了，那么也许也可以去探究一下在transparent下如何优化动画性能。

代码的功能一点点增加，程序体积越来越大，几kb，几十kb。目前的做法是尽量保证touch的纯粹性，其他功能全部成为独立项目或独立进程。这样的后果是，现在依赖的是fx就还好，一个程序4kb磁盘占用起步，如果切换到不带运行时net8，config，json，apphost一堆文件加起来160kb。如果自己dotnet dll的话，只需要6kb（need runtimeconfig.json），但也不是很想考虑。如果是native，就是1mb起步的体积。

因为touch的特性（跟随游戏窗口handle的生命周期），main的ErogeHelper也要保活，驻后台，跟随游戏进程的生命周期。

但是体积小应该只是一个可选的优势，更注重体验，程序性能，内存占用。

所以不带运行时是坠好的。ErogeHelper的理想形态应该是，简易使用的，存在感低的，稳定的，功能性的，轻量的（可选择的更小体积），流畅的，原生的（代码实现，依赖少）。

winforms确定可以native，毫无疑问如果要实现虚拟键盘，那么必然使用winforms。如果要显示文本或弹幕，还得引入多样资源依赖。也可以考虑只针对native版释放这些功能

skiasharp虽然版本号似乎很低m88。。skiasharp也可以直接读入渲染html ruby到wpf感觉蛮有趣，doc

所以最终我想要重新打量整个erogehelper的形态，优化启动时的交互方式，文件列表现在的样子就好了吗？如果是native的话那怎样才好？项目列表也是现在这样就行吗？要不要把他们又合在一起成单文件。或者成为dll的形式。还是以右键菜单为主体，Preference从那里启动就好了吗，要不要切换到fluent desing，只是一个设置面板的话，用什么框架都可以没差吧。

当我确定从文本提取和机器翻译移动到为仅针对平板优化体验时，就假设了不考虑win7设备，说起来win7也是有很多平板设备的，还有很多的学校电脑。随着时间迁移相比win8.1设备也会越来越少吧，本身win7就比win8多了。那些diy的带电池的win7游戏机，感觉也是完全可能的。

类似keyMapping，这样的小程序，native net8 也太不划算了。1mb起步，本身代码量没有多少改写成c++的话才十多kb，并且和native等价也是需要编译不同平台。net项目的keymapping唯一适合netfx。或者winform native已经够大了。也不计较这1mb，主要省去运行时。