我的两个屏幕之一的DataGridView的可怕的重绘性能 [英] Horrible redraw performance of the DataGridView on one of my two screens

问题描述

我的双显示器系统上的DataGridView遇到了一个非常奇怪的问题，我已经解决了这个问题， 。这个问题表现为对控件的极度缓慢的重绘（像完整重绘的30秒，），只有当它在我的一个屏幕上时。当另一方面，重绘速度很好。我有一个nVidia 8800 GT与最新的非beta驱动程序（175.某事）。是驱动程序的错误？我会把它留在空中，因为我不得不忍受这种特殊的配置。 （它不会发生在ATI卡上，虽然...）

绘制速度与单元格内容无关，自定义绘图不会提高性能甚至在绘制一个实心矩形的时候。

我后来发现在表单上放置一个ElementHost（来自System.Windows.Forms.Integration命名空间）正确问题。它不必搞砸，它只需要是DataGridView的形式的孩子。只要可见属性为true，它可以调整为（0，0）。

不想明确添加.Net 3 /3.5依赖于我的应用程序，我创建一个方法来创建这个控制在运行时（如果可以）使用反射。它的工作原理至少在没有所需库的机器上正常运行 - 它只是恢复缓慢。

此方法还允许我在应用程序运行时应用修复，从而更容易看出我的表单上的WPF库正在更改（使用Spy ++）。 p>

经过大量的试用和错误，我注意到，启用双缓冲控件本身（而不只是表单）纠正了这个问题！

---

所以，您只需要根据DataGridView进行自定义类，以便您可以启用其DoubleBuffering。就是这样！

  class CustomDataGridView：DataGridView 
 {
 public CustomDataGridView（）
 {
 DoubleBuffered = true; 
} 
} 
  

只要我的网格实例都是使用这个定制版本，一切都很好。如果我遇到这样的情况，我无法使用子类解决方案（如果我没有代码），我想我可以尝试将该控件注入到表单:)（虽然我会更有可能尝试使用反射来强制从外部的DoubleBuffered属性再次避免依赖）。

令人难过的是，这么简单的东西吃了我这么多时间...

解决方案

您只需要根据DataGridView创建一个自定义类，以便可以启用其DoubleBuffering。就是这样！

  
 class CustomDataGridView：DataGridView 
 {
 public CustomDataGridView（）
 {
 DoubleBuffered = true; 
} 
} 
  

只要我的网格实例都是使用这个定制版本，一切都很好。如果我遇到这样的情况，我无法使用子类解决方案（如果我没有代码），我想我可以尝试将该控件注入到表单:)（虽然我'更有可能尝试使用反射来强制从外部的DoubleBuffered属性再次避免依赖）。

很遗憾，这样一个简单的事情吃了我的时间很多...

注意：让答案成为一个答案，所以问题可以被标记为回答

I've actually solved this, but I'm posting it for posterity.

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.

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.

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.

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!

---

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;
    } 
}

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...

解决方案

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;
    } 
}

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

这篇关于我的两个屏幕之一的DataGridView的可怕的重绘性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！