如何防止控件在 TableLayoutPanel 内调整大小时视觉上滞后？
我有一个基于多个嵌套 TableLayoutPanel 的中等复杂度的布局。调整窗体大小会导致更深嵌套表内的控件在视觉上滞后于调整大小。首先，这使得它们看起来像是在调整表单大小时四处移动，但更糟糕的是，当它们滞后到足以离开分配的表格单元格时，控件的边缘明显被剪切。
有什么方法可以防止这种情况发生，或者这是最好的 TableLayoutPanel 可以做到的吗？
编辑：在尝试了很多程序后，我得出的结论是，调整大小时的滞后是一个普遍存在的问题。对我来说，似乎每个人都已经接受了这是不可避免并且可以接受。当然，如果它实际上不可避免，那么接受就容易多了:)
查看您最喜欢的“良好 UI”程序中的延迟的最简单方法：通过按住左边界并观察所有右对齐控件跳转（或者顶部边界和底部对齐控件，例如状态栏）。四周都坏了。
如果有人能提供充分的理由来解释为什么在使用本机 Windows 控件时这是不可避免的，我会接受这个答案。另外，如果您发现一个使用本机控件的程序不会遇到此问题，请说出来，这可能会有所帮助......
I have a layout of medium complexity based on several nested TableLayoutPanels. Resizing the form causes the controls inside the deeper nested tables to visually lag behind the resize. Firstly, this makes them look like they move around while the form is being resized, but worse, the edges of the controls are visibly clipped when they lag enough to leave their allocated table cells.
Is there any way to prevent this or is this the best TableLayoutPanel can do?
Edit: Having experimented with a bunch of programs I came to the conclusion that lag on resize is a ubiquitous problem. To me, it seems that everyone has resigned that this is inevitable and acceptable. Of course if it's actually inevitable then accepting this is that much easier :)
The easiest way to see the lag in your favourite "good UI" program: resize it by holding the left boundary and watch all right-aligned controls jump around (or alternatively, top boundary & bottom-aligned controls, like statusbars). It's broken all around.
If anyone could provide good reasons why this is inevitable when using native windows controls I will accept that answer. Also, if you find a program using native controls that doesn't suffer this please say so, this could help...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Windows 中本机控件的问题是每个控件都负责绘制自身，这意味着将位图绘制到屏幕上。当容器控件中的每个控件调整大小时，它所占据的窗口区域将变得无效，因此不仅容器中的每个控件要重新绘制，容器本身也必须重新绘制。此外，调整大小/重绘事件都发生在 UI 线程上，因此它是单线程操作。
自从 16 位 Windows 引入以来，本机窗口绘制背后的基本机制就没有改变。
人们使用许多技巧来尝试解决这个问题，例如双缓冲、离屏渲染或简单地禁用调整大小。
要了解它应该是什么样子，请查看 WPF。 MS 开发它是为了解决这个问题。
如果 WPF 不是一个选项，并且您使用的是 Windows 窗体，请查看 布局 相关文档。您可以实现自己的布局引擎，而不是依赖开箱即用的微软产品。
The problem with native controls in windows is that each control is responsible for drawing itself which means painting a bitmap to the screen. As each control in a container control is resized the region of the window it occupies becomes invalidated so not only does each control in the container repaint, the container itself must repaint. Also, the resize/repaint events are all occuring on the UI thread so it's a single threaded operation.
The basic mechanisms behind native window drawing haven't changed since 16 bit windows introduced it.
There are many tricks(hacks) that people employ to try and get around the problem, things like double buffering, off screen rendering, or simply disabling resizing.
To see how it should be, look at WPF. MS developed it as a means of solving this problem.
If WPF isn't an option and you are using windows forms check out the layout related documentation from microsoft. You can implement your own layout engine as opposed to relying on the out of the box microsoft offerings.
这似乎根本不可能，包括 WPF（实际上更糟糕 - 请参阅 这个问题）。 Qt 可以避免这种延迟，除非启用了 Aero。叹...
This doesn't seem to be possible at all, including WPF (which is actually even worse - see this question). Qt can avoid such lag, except if Aero is enabled. Sigh...
设置
DoubleBuffered = true。您可以在表格上进行设置。Set
DoubleBuffered = true. You can set it on the forms.