我遇到了与我的双显示器系统DataGridView的一个非常奇怪的问题。这个问题表现为控制的非常缓慢重绘（像30秒的全重绘的），但只有当它在我的屏幕之一。在另一方面，重绘速度罚款。我有一个的nVidia 8800 GT与最新的非测试版驱动程序（175的东西）。它是一个驱动程序错误？我会离开，在空中，因为我生活在这种特定的配置。 （它不会发生在ATI显卡，虽然...）

I ran into a very odd issue with the DataGridView on my dual-monitor system. The issue manifests itself as an EXTREMELY slow repaint of the control (like 30 seconds for a full repaint), but only when it is on one of my screens. When on the other, the repaint speed is fine. I have an nVidia 8800 GT with the latest non-beta drivers (175. something). Is it a driver bug? I'll leave that up in the air, since I have to live with this particular configuration. (It does not happen on ATI cards, though...)

油漆速度无关的单元格内容，并自定义绘制没有改善的性能在所有 - 即使只是画了坚实的矩形

The paint speed has nothing to do with the cell contents, and custom drawing doesn't improve the performance at all - even when just painting a solid rectangle.

后来我才发现，在窗体上放置一个ElementHost的（从System.Windows.Forms.Integration命名空间）可以解决该问题。它没有用，它只是需要的形式为孩子在DataGridView也是上搞砸。它可以调整为（0，0），只要所述的可见的属性是正确的。

I later find out that placing a ElementHost (from the System.Windows.Forms.Integration namespace) on the form corrects the problem. It doesn't have to be messed with, it just needs to be a child of the form the DataGridView is also on. It can be resized to (0, 0) as long as the Visible property is true.

不想要的净3 / 3.5依赖明确添加到我的应用程序，我做的方法来创建这个控件在运行时（如果可以）使用反射。它的工作原理，以及至少它没有正常上不具备所需的库的机器 - 它只是可追溯到正在缓慢。

Not wanting to explicitly add the .Net 3/3.5 dependency to my app, I make a method to create this control at runtime (if it can) using reflection. It works, and at least it fails gracefully on machines that don't have the required library - it just goes back to being slow.

这个方法也让我的应用程序运行时修复，使其更容易看到的WPF库正在改变我的形式（使用间谍+ +）。

This method also lets me apply to fix while the app is running, making it easier to see what the WPF libraries are changing on my form (using Spy++).

在大量的试验和错误，我注意到，在控制本身启用双缓冲（而不是只是形式）纠正了问题！

After a lot of trial and error, I notice that enabling double buffering on the control itself (as opposed to just the form) corrects the issue!

所以，你只需要根据过的DataGridView的自定义类，所以你可以启用它DoubleBuffering。这就是它！

So, you just need to make a custom class based off of DataGridView so you can enable its DoubleBuffering. That's it!

class CustomDataGridView: DataGridView
{
    public CustomDataGridView()
    {
        DoubleBuffered = true;
    } 
}

只要所有网格我的实例都采用这种定制版，一切都很好。如果我遇到这种情况造成这个的地方我不能够使用子类的解决方案（如果我没有在code），我想我可以尝试该控件到窗体注入:)（ 虽然我会更倾向于尝试使用反射来从外部强制的DoubleBuffered财产再次避免依赖的）。

可悲的是，这样一个平凡简单的事吃了这么多我的时间...

It is sad that such a trivially simple thing ate up so much of my time...

推荐答案

您只需要根据过的DataGridView的自定义类，所以你可以启用它DoubleBuffering。这就是它！

You just need to make a custom class based off of DataGridView so you can enable its DoubleBuffering. That's it!

class CustomDataGridView: DataGridView
{
    public CustomDataGridView()
    {
        DoubleBuffered = true;
    } 
}

只要所有网格我的实例都采用这种定制版，一切都很好。如果我遇到这种情况造成这个的地方我不能够使用子类的解决方案（如果我没有在code），我想我可以尝试该控件到窗体注入:)（虽然我会更倾向于尝试使用反射来迫使DoubleBuffered属性从外部再次避免依赖）。

As long as all of my instances of the grid are using this custom version, all is well. If I ever run into a situation caused by this where I'm not able to use the subclass solution (if I don't have the code), I suppose I could try to inject that control onto the form :) (although I'll be more likely to try using reflection to force the DoubleBuffered property on from the outside to once again avoid the dependency).

可悲的是，这样一个平凡简单的事吃了这么多我的时间...

It is sad that such a trivially simple thing ate up so much of my time...

注：使答案的答案，所以这个问题可以被标记为回答

Note: Making the answer an answer so the question can be marked as answered