1. 从闪烁的绘图板说起为什么需要双缓冲如果你用Qt做过自定义绘图控件大概率遇到过这样的场景窗口里画了几十个图元鼠标拖动时画面开始疯狂闪烁线条像在抽搐填充区域忽明忽暗。用户第一反应是这软件做得真烂但代码逻辑明明没问题。这个问题的根源不在你的算法而在绘制机制本身——每一次重绘请求都会先擦除背景再逐层绘制内容擦除和绘制之间的时间差被人眼捕捉到了就成了闪烁。Qt4时代这个问题尤其突出因为当时很多开发者习惯直接在paintEvent里堆砌QPainter的绘制指令图元一多每帧的绘制耗时就被拉长闪烁几乎不可避免。解决思路其实很朴素既然问题是擦除和绘制不同步造成的那就别让用户看到中间过程——先把所有内容画到一块看不见的画布上等整帧画完了再一次性把这块画布贴到屏幕上。这就是双缓冲Double Buffering的核心思想。Qt4里实现双缓冲有两条路一条是手动管理一个QPixmap作为离屏画布在paintEvent里先画到pixmap再drawPixmap到窗口另一条是直接给QWidget设置WA_PaintOnScreen之外的属性配合QPainter的自动缓冲。第五章5.4节讲的正是前者——手动双缓冲因为它的可控性最强也最能帮你理解底层发生了什么。这篇笔记适合已经写过Qt自定义控件、被闪烁问题折磨过、想彻底搞明白绘制流程的开发者。如果你还在用QLabel贴图阶段建议先把paintEvent的基本用法摸熟再来看。2. 手动双缓冲的完整实现链路2.1 离屏画布的创建时机与尺寸管理手动双缓冲的第一步是准备一块离屏画布。在Qt4里通常用QPixmap因为它针对屏幕显示做了优化比QImage更适合做缓冲。关键问题是这块画布什么时候创建、尺寸怎么定很多教程会告诉你在构造函数里创建一个和窗口一样大的pixmap但这是有坑的。窗口大小会变用户拖拽边框、最大化、切换分辨率pixmap尺寸如果不跟着变要么画不全要么拉伸变形。正确的做法是在resizeEvent里检查并重建缓冲void MyWidget::resizeEvent(QResizeEvent *event) { if (buffer.size() ! event-size()) { buffer QPixmap(event-size()); buffer.fill(Qt::white); // 或用背景色填充 } QWidget::resizeEvent(event); }这里有个细节值得说buffer.fill()这一步不能省。QPixmap刚创建时内容是未定义的如果不填充第一次绘制前那块区域可能是花屏。填充色要和控件背景一致否则双缓冲反而会引入新的视觉瑕疵。另一个容易忽略的点是设备像素比。Qt4时代高DPI屏幕还不普遍但如果你在Qt5/6里沿用这套代码必须考虑devicePixelRatio否则在Retina屏上缓冲图会模糊。Qt4的QPixmap没有这个烦恼但知道这个演进对理解后续版本有帮助。2.2 paintEvent里的绘制顺序与状态隔离有了缓冲画布paintEvent的写法就变了。核心原则是所有绘制指令都作用于buffer最后只做一次blit。看代码void MyWidget::paintEvent(QPaintEvent *event) { QPainter painter(buffer); // 先清空缓冲 painter.fillRect(buffer.rect(), Qt::white); // 在这里画所有图元 drawGrid(painter); drawShapes(painter); drawSelection(painter); painter.end(); // 一次性贴到窗口 QPainter screenPainter(this); screenPainter.drawPixmap(0, 0, buffer); }这段代码里有几个关键决策。第一painter的作用域要严格控制画完buffer必须end()否则后面的screenPainter可能拿不到有效的绘制上下文。第二清空缓冲用fillRect而不是依赖buffer.fill()因为fill()在每帧都调用会有性能开销而fillRect可以只清需要重绘的区域——虽然简单实现里我们清全部但知道这个优化点很重要。第三也是最容易出错的不要在buffer的painter还活着的时候创建窗口的painter。Qt的绘制系统在同一时刻对同一个设备只允许一个活跃的QPainter虽然buffer和窗口是两个设备但某些平台实现下交叉创建会出问题。养成先画完buffer、end掉、再开窗口painter的习惯能避开很多玄学bug。2.3 局部重绘与全量重绘的取舍双缓冲最直接的代价是内存和带宽每帧都要把整块缓冲贴到窗口哪怕只改了一个像素。对于小控件无所谓但如果你的画布是4K分辨率、每秒重绘60次这个开销就很可观了。Qt提供了update(const QRect rect)来指定重绘区域配合event-rect()可以在paintEvent里只处理脏区域。但双缓冲和局部重绘结合时有个矛盾buffer里保存的是上一帧的完整内容如果你只重绘脏区域buffer的其他部分还是旧的直接blit会覆盖掉窗口上本来正确的区域。解决办法是blit时也只贴脏区域QPainter screenPainter(this); screenPainter.drawPixmap(event-rect(), buffer, event-rect());这样窗口上只有脏区域被更新其他区域保持原样。但前提是buffer里对应区域的内容是正确的——这就要求你在画buffer时脏区域内的内容必须完整重绘不能依赖buffer里的旧数据。实践中如果图元之间有重叠、遮挡关系局部重绘的逻辑会变得很复杂很多项目干脆放弃局部优化直接全量重绘。我的建议是先跑通全量双缓冲确认闪烁消失后再根据性能分析结果决定是否做局部优化。过早优化只会让代码难以维护。3. 那些年双缓冲踩过的坑3.1 缓冲图未填充导致的随机花屏前面提过buffer.fill()不能省但实际项目中这个坑的表现形式很迷惑。有时候程序启动正常拖动窗口后才花屏有时候在开发机上没事换台机器就出问题。原因是QPixmap的未初始化内存在不同平台、不同驱动下的表现不一致。有的平台会返回全黑有的返回随机数据有的甚至返回上一块被释放的内存内容。更隐蔽的是如果你在resizeEvent里重建buffer但忘了填充窗口放大时新增的区域就是未定义的。用户看到的是窗口边缘出现雪花点或彩色条纹第一反应是显卡坏了。这个问题的排查成本很高因为它在调试器里往往复现不了——调试器的内存环境和正常运行不同。记住一条铁律任何新创建的QPixmap或QImage在作为绘制目标之前必须填充背景色。这不是可选的优化是正确性要求。3.2 在paintEvent里创建QPainter的嵌套陷阱Qt4的QPainter有个特性在paintEvent里如果你用QPainter painter(this)Qt会自动帮你做一些缓冲处理取决于平台。但如果你同时手动管理buffer就可能出现双重缓冲——系统缓冲一层你的buffer一层反而增加了开销甚至在某些嵌入式平台上导致绘制错乱。判断是否需要手动双缓冲的一个简单方法先不写buffer直接在paintEvent里画如果闪烁不严重说明Qt自带的缓冲够用如果闪烁明显再引入手动buffer。不要一上来就套双缓冲模板那是不必要的复杂度。另外QPainter的构造和析构本身有开销。在paintEvent里频繁创建两个QPainter对象一个给buffer一个给窗口如果重绘频率很高这个开销会累积。优化方法是在类里持有buffer的QPainter成员但这样又引入了状态管理的复杂度。折中方案是只在确实需要时才创建不要为了看起来优雅而提前优化。3.3 缓冲尺寸与窗口尺寸不同步的连锁反应这个坑我在一个绘图项目里真实踩过。当时在构造函数里创建了buffer(800, 600)窗口默认也是800x600一切正常。后来用户最大化窗口paintEvent里blit的时候只贴了800x600的区域右边和下边出现大片空白。更糟的是鼠标坐标映射还按800x600算点击位置和实际图元对不上。修复方法就是在resizeEvent里同步buffer尺寸但要注意重建buffer会丢失内容。如果你的绘制是增量式的比如只画新增的线条依赖buffer里的旧内容重建后必须触发一次全量重绘。这就是为什么很多绘图程序在窗口大小改变时会闪一下——它在重建缓冲并重画所有内容。问题现象根本原因修复方式窗口边缘花屏buffer未填充或尺寸不匹配resizeEvent里重建并fill拖动时图元错位坐标映射未随buffer更新统一用buffer尺寸做坐标变换最大化后内容缺失blit区域小于窗口drawPixmap用buffer完整区域重绘后旧内容残留增量绘制依赖了失效的buffer重建后强制全量重绘4. 双缓冲之外Qt绘制性能的进阶思路4.1 什么时候该放弃手动双缓冲手动双缓冲不是银弹。如果你的控件图元数量少比如少于50个、绘制逻辑简单Qt自带的缓冲机制完全够用手动加一层反而增加代码量和内存占用。判断标准很简单用Qt自带的绘制方式在目标硬件上实测是否闪烁。不闪就别折腾。另一个信号是当你发现双缓冲的代码里充满了什么时候该重建buffer什么时候该全量重绘脏区域怎么算这些分支逻辑时说明你的场景已经复杂到手动管理不划算了。这时候应该考虑换用QGraphicsView框架它内置了场景图管理和高效的局部重绘机制虽然学习曲线陡一点但长期维护成本低得多。4.2 从QPixmap到QImage的切换时机QPixmap依赖平台原生绘图后端在X11、Windows、macOS上的行为有细微差异。如果你需要逐像素操作缓冲比如做图像处理算法、像素级碰撞检测QImage更合适因为它保证内存布局一致。代价是QImage到屏幕的blit比QPixmap慢因为多了一次格式转换。实践中的策略是绘制阶段用QPixmap需要像素访问时临时转QImage。转换用QPixmap::toImage()和QImage::toPixmap()但注意这两个操作都是深拷贝频繁转换会拖慢性能。如果像素访问是每帧都做的那就直接用QImage做缓冲接受blit的开销。4.3 垂直同步与帧率控制的现实约束双缓冲解决了擦除-绘制不同步的问题但解决不了绘制速度超过屏幕刷新率导致的撕裂。Qt4没有内置的垂直同步控制update()只是标记重绘请求实际绘制时机由事件循环决定。如果你在定时器里以100Hz调用update()而屏幕只有60Hz多出来的帧就是浪费。控制帧率的土办法是用QTime记录上次重绘时间不够间隔就跳过void MyWidget::timerTick() { if (lastFrame.elapsed() 16) return; // 约60fps lastFrame.restart(); update(); }这个做法不精确但足够应付大多数交互场景。真正的垂直同步需要平台相关代码Qt4时代很少有人这么做因为当时的硬件和驱动支持参差不齐。5. 一个可复用的双缓冲控件骨架把上面的经验整合起来我通常会用这样一个骨架作为自定义绘图控件的起点。它不是最优的但足够稳健能避开大部分常见坑class BufferedWidget : public QWidget { public: BufferedWidget(QWidget *parent nullptr) : QWidget(parent) { setAttribute(Qt::WA_OpaquePaintEvent); // 告诉Qt不需要擦背景 setAttribute(Qt::WA_NoSystemBackground); } protected: void resizeEvent(QResizeEvent *event) override { if (buffer.size() ! event-size()) { buffer QPixmap(event-size()); buffer.fill(backgroundColor()); needsFullRedraw true; } QWidget::resizeEvent(event); } void paintEvent(QPaintEvent *event) override { QPainter painter(buffer); if (needsFullRedraw) { painter.fillRect(buffer.rect(), backgroundColor()); drawAll(painter); needsFullRedraw false; } else { painter.setClipRect(event-rect()); drawRegion(painter, event-rect()); } painter.end(); QPainter screenPainter(this); screenPainter.drawPixmap(event-rect(), buffer, event-rect()); } virtual void drawAll(QPainter *painter) 0; virtual void drawRegion(QPainter *painter, const QRect rect) { drawAll(painter); } private: QPixmap buffer; bool needsFullRedraw true; };这个骨架里有两个设计决策值得解释。WA_OpaquePaintEvent告诉Qt这个控件会自己画满整个区域Qt就不用先擦背景了省一次填充。WA_NoSystemBackground进一步阻止系统背景绘制。这两个属性配合双缓冲能把每帧的绘制操作降到最少。drawRegion默认调用drawAll子类如果实现了高效的局部绘制就重写它没实现也不影响正确性。这种默认安全、可选优化的设计比强制子类实现局部绘制要友好得多。最后说一个实际使用中的体会双缓冲的buffer不要用智能指针管理直接用值成员。QPixmap本身有隐式共享拷贝开销很小值语义反而让生命周期更清晰。我见过用QSharedPointerQPixmap的写法除了增加一层间接访问没有任何好处。Qt的值类设计就是让你直接用的别被其他语言的对象必须堆分配思维带偏了。
