如何防止控件在 TableLayoutPanel 内调整大小时视觉滞后？答案

【问题标题】：How to prevent controls visually lagging behind on resize inside TableLayoutPanel?如何防止控件在 TableLayoutPanel 内调整大小时视觉滞后？
【发布时间】：2009-08-26 09:23:14
【问题描述】：

我有一个基于多个嵌套TableLayoutPanels 的中等复杂度的布局。调整窗体大小会导致更深的嵌套表中的控件在视觉上落后于调整大小。首先，这使得它们看起来像是在调整窗体大小时四处移动，但更糟糕的是，当它们滞后到离开分配的表格单元格时，控件的边缘会明显被剪裁。

有什么方法可以防止这种情况发生吗？或者这是TableLayoutPanel 可以做到的最好的方法吗？

编辑：在尝试了一堆程序后，我得出结论，调整大小的延迟是一个普遍存在的问题。对我来说，似乎每个人都已经接受了这是不可避免的和可以接受的。当然，如果它实际上是不可避免，那么接受就容易多了:)

在您最喜欢的“优秀 UI”程序中查看延迟的最简单方法：按住左边界调整它的大小并观察所有右对齐的控件（或者，上边界和下对齐的控件，如状态栏） .周围都坏了。

如果有人能提供充分的理由说明在使用本机 Windows 控件时这是不可避免的，我会接受这个答案。另外，如果您发现使用本机控件的程序不会出现这种情况，请说出来，这可能会有所帮助...

【问题讨论】：

Skype 聊天窗口不使用本机控件，但奇怪的是它不会滞后 - 除非 Vista Aero 已启用，在这种情况下，控件会严重滞后.找不到任何其他受 Aero 影响的应用。

标签： .net winforms resize tablelayoutpanel

【解决方案1】：

Windows 中原生控件的问题在于每个控件都负责绘制自身，这意味着将位图绘制到屏幕上。当容器控件中的每个控件都调整大小时，它占据的窗口区域变得无效，因此不仅容器中的每个控件都重新绘制，容器本身也必须重新绘制。此外，调整大小/重绘事件都发生在 UI 线程上，因此它是单线程操作。原生窗口绘制背后的基本机制自 16 位窗口引入以来没有改变。

人们使用许多技巧（hacks）来尝试解决问题，例如双缓冲、离屏渲染或简单地禁用调整大小。

要了解它应该如何，请查看 WPF。 MS 开发它是为了解决这个问题。

如果 WPF 不是一个选项并且您使用的是 Windows 窗体，请查看来自 microsoft 的 layout 相关文档。您可以实现自己的布局引擎，而不是依赖开箱即用的微软产品。

【讨论】：

我在 WPF 中尝试过同样的事情，令人惊讶的是，存在非常相同的问题 :) 尝试一下 - 创建一个右下角对齐的按钮并根据左上角调整表单的大小。

【解决方案2】：

这似乎根本不可能，包括 WPF（实际上更糟 - 请参阅this 问题）。 Qt 可以避免这种延迟，除非启用 Aero。叹息……

【讨论】：

【解决方案3】：

设置DoubleBuffered = true。您可以在表单上设置它。

【讨论】：