MFC多线程调用CClientDC绘制是否可行及高速绘制方案咨询

关于CClientDC多线程绘制的可行性 #

该方案完全不具备可行性，你遇到的乱码问题不是业务代码编写错误，是方案本身的机制冲突导致的：

• Windows GDI的核心对象（包括HDC、HPEN、HFONT等）天生具备线程亲和性，同一窗口对应的屏幕HDC全局只有一份，即便你在不同线程创建独立的CClientDC实例，底层绑定的都是同一个HDC，所有绘制请求会被GDI全局锁强制串行执行，不仅拿不到任何并发收益，还会额外增加线程切换、锁竞争的开销。
• HDC的绘制属性（文本颜色、背景模式、当前选入的字体、坐标原点等）是DC全局共享的，多线程并发调用时，A线程刚设置好亮绿色文本属性，B线程可能马上修改了DC的文本颜色或者位图选入状态，A线程执行TextOut时用到的属性已经被篡改，自然会出现乱码、花屏的问题。

20ms内完成2000字符绘制的替代实现 #

按照优化优先级从高到低落地，单线程即可稳定跑到60帧以上，单帧耗时可以压到10ms以内：

• 首先落地内存双缓冲机制，彻底抛弃直接往CClientDC逐字符TextOut的逻辑。创建和窗口客户区尺寸一致的兼容内存DC与DIB位图，所有字符绘制操作全部在内存DC上完成，整帧绘制结束后，仅调用一次BitBlt把内存DC的完整内容一次性拷贝到屏幕CClientDC。这一步可以消除逐字符绘制时频繁触发的屏幕区域刷新IO开销，直接把原TextOut方案的耗时砍掉70%以上。
• 做预渲染字体缓存优化。代码雨用的是等宽字体，所有字符的宽高固定，你可以提前把效果需要用到的所有日文片假名、数字、符号按不同亮度等级的绿色预渲染成小位图存在数组里，绘制时不需要调用TextOutW，直接用BitBlt把对应字符的小位图贴到内存DC的对应方格位置，能再砍掉60%左右的GDI调用开销。
• 只更新脏区域，不要每帧全量重绘所有方格。代码雨效果本身每帧只有下落的字符头、新增的渐变尾迹需要更新，大部分已经暗到接近黑色的旧方格完全不需要重复绘制，维护一个待更新方格的列表，每帧只处理列表里的方格即可，需要绘制的字符量可以从数千级压到数百级。
• 如果追求极致性能，可以直接操作DIB段的原始像素内存：提前把字符的像素点阵存成字节数组，绘制时直接把字符像素按偏移写到DIB的内存指针里，全程不调用任何GDI绘制函数，2000个字符的绘制耗时可以压到1ms以内。

补充注意：多线程可以用，但只适合用来做字符位置、亮度变化的逻辑计算，绝对不要碰任何GDI绘制相关的操作。计算线程把每帧待更新的方格数据存在线程安全的队列里，最终所有绘制操作统一放到UI线程执行即可，完全不会出现卡顿。

内容的提问来源于stack exchange，提问作者Estelyen