winform容器内动态生成大量控件，需解决拖动时卡顿的问题。

[ddsxd19]

做了一个winform界面，放了一个panel，界面加载时panel内按需要动态生成了很多控件，panel大小超出了窗体范围。
该界面类似某场景全景图，已做好panel鼠标拖动功能，以显示范围外的部分。（另外也做了类似游戏的右下角小地图可拖动矩形选框同步窗体显示范围）。
目前的问题是，拖动panle就要改变Location，改变Location就要重绘窗体内的所有控件，重绘就要闪烁(已解决)，用双缓冲不闪烁了拖动过程又变得非常卡顿，查到吐血也没找到好的解决办法(不考虑用wpf)。
想求教：
1.是否有办法在panel不改变Location的情况下，通过改变窗体的显示区域(就好像通过窗户看后面的东西)，实现panel的拖动效果？这样一切都不用重绘了。
2.如果1没有办法实现，那有什么办法可以最大程度优化winform窗体，在有大量控件的情况下，拖动、缩放（需重绘）时可以变的流畅，或者有什么办法可以不用重绘。
简单来说，就是在有大量控件的情况下，如何实现流畅的拖动。关键是流畅。
求大神指点！！！

闪烁问题是下面代码解决的：
/// <summary>
/// 重写CreateParams方法
/// 解决控件过多加载闪烁问题
/// </summary>
protected override CreateParams CreateParams
{
get
{
CreateParams cp = base.CreateParams;
cp.ExStyle |= 0x02000000;//用双缓冲绘制窗口的所有子控件
return cp;
}
}

[ddsxd19]

引用 1 楼 kobehahaha 的回复:

你应该是onpaint 里面写了所有重绘吧 所有拖动时候就一直要画 才卡的 可以把重绘的过程单独出来

没有在onpaint 写重绘，现在就是单纯考虑在一个容器内（panel）动态生成大量控件，然后拖动容器时（在MouseMove中改变容器的Location）出现的闪烁和卡顿。

[非专业开发Five]

大量是多大？过大（超过5000）建议用dxui或wpf解决问题，否则卡是肯定的。

[ddsxd19]

引用 3 楼 xomix 的回复:

大量是多大？过大（超过5000）建议用dxui或wpf解决问题，否则卡是肯定的。

容器内动态生成80多个自定义控件，每个自定义控件中80多个label加几个Button。我试着想想办法减少合并些控件看看会不会好点。 但是控件再多，如果不动也不会卡，我想找动窗口不动内容实现拖动的办法，或者其它方法绕过控件重绘问题的方法，或者是提升性能的方法。

[非专业开发Five]

引用 4 楼 ddsxd19 的回复:

[quote=引用 3 楼 xomix 的回复:] 大量是多大？过大（超过5000）建议用dxui或wpf解决问题，否则卡是肯定的。

容器内动态生成80多个自定义控件，每个自定义控件中80多个label加几个Button。我试着想想办法减少合并些控件看看会不会好点。 但是控件再多，如果不动也不会卡，我想找动窗口不动内容实现拖动的办法，或者其它方法绕过控件重绘问题的方法，或者是提升性能的方法。[/quote] 那是你以为，5000+控件拖动，移动滚动条，变更大小都会卡。 640按道理不会卡的，你的自定义控件是不是拦截了重绘？

[exception92]

查到吐血也没找到好的解决办法(不考虑用wpf) -》直接杀死比赛！ ！大量控件情况下 win32/GDI在绘制控件方面本来是有劣势的。用wpf中的DrawXX类，绘制上万个很轻松，不过对显卡要求高点。

[以专业开发人员为伍]

不显示的控件不要加载，加载了但是超出显示范围的控件也应该及时清除。

[以专业开发人员为伍]

另外，大部分拖动，应该拖动一个虚拟快照，例如一个“边框”或者一个图片截图，而不是拖动一大堆控件。

[ddsxd19]

我把部分没有交互需求的控件统一用图片代替后控件少了很多性能也提高很多，目前能接受了。 以后再有类似的需求就用WPF吧，谢谢大家！结贴散分！

[ddsxd19]

用两张小图片的性能比只用一张大图片的性能要高。

[百合杰]

你应该是onpaint 里面写了所有重绘吧 所有拖动时候就一直要画 才卡的 可以把重绘的过程单独出来

[qq_40058126]

@ddsxd19你的这个问题解决了没有，兄弟！