WPF就是一种direct ui，顶层窗口就是普通的win32 HWND，HWND用的是win32的keyboard/mouse队列，在此基础上根据自己维护的direct ui控件的树结构/Z轴顺序/焦点情况来转换并分发win32的keyboard/mouse消息。

【 在 iwantfly 的大作中提到: 】
: 1. wpf不使用win32的消息队列， 阻塞最严重的后果不是延迟， 而是消息丢失， ChatGPT不准确
: 2. ToolTip没有mouse hover消息需要自己实现
: 3. 避免ui阻塞时卡死渲染，不知道ai是怎么理解的， ui阻塞卡死渲染想做什么？？？
: ...................
--
FROM 111.199.144.*

确实还有一些场景是必须用 Native App 的，但这些场景的范围越来越窄了。
有些比较经典的应用，比如像 PhotoShop、3DS 这种的非常重，开发和运维可能也只有大厂才能负担了。

【 在 hgoldfish 的大作中提到: 】
: 主要是写各种软件总得有个 UI 落地的方案吧。
: 大多数当然选择纯 Web 了。但是总有一些场景，不得不使用 native app 来落地。
: 所以工作久一点的程序员一般都会懂点 Qt, Android 这些东东。
: ...................
--
FROM 61.185.195.*

好像win的基本定时器精度就是十几毫秒。不知道现在改进了没有。
【 在 iwantfly 的大作中提到: 】
: 1. wpf的设计对绘制、系统响应要求极高，按照60fps，事件响应大于16ms就会卡顿,丢帧，闪烁, 而且后果极其严重，比如阻塞导致mouse move消息消失，鼠标位置与响应不同步
: 2. 完成度不够，不够成熟，高频消息需要自己hack来实现平滑移动效果，定时器能差个几十毫秒,很多基础的功能都得自己实现， 比如ToolTip
: 3. wpf的使用独特的ui渲染双线程模型，大部分第三方技术采用消息队列和UI绘制在主线程,导致其利用既有成熟的第三方库极其困难
: ...................
--
修改:ylh1969 FROM 221.218.61.*
FROM 221.218.61.*

win32就是：x86(32-bit) + x陆肆

【 在 ylh1969 的大作中提到: 】
: 问个低级问题。
: win32api是否支持win63＋1？
--
FROM 111.199.144.*

c++的因为内存管理难，所以有比较强大的分析工具，跑出泄露场景后，有些工具甚至能直接指出是在哪一句代码new出来的东西没有delete.
c#里，内存管理分为managed的非managed的，managed的部分是用垃圾回收管理的，相对会简单一些，而非managed的，需要手动释放。
--
FROM 123.118.11.*