I'm using a custom control in an ultragrid column, defined like this :
UltraControlContainerEditor container = new UltraControlContainerEditor();container.RenderingControl = new MyControl(); cols["MyColumn"].EditorComponent = container; cols["MyColumn"].CellDisplayStyle = CellDisplayStyle.FullEditorDisplay;
the grid's row appearance is defined with a gradient like this
UltraGrid.DisplayLayout.Bands[0].Override.RowAppearance.BackColor = System.Drawing.Color.White;UltraGrid.DisplayLayout.Bands[0].Override.RowAppearance.BackColor2 = System.Drawing.Color.FromArgb(191, 219, 255);UltraGrid.DisplayLayout.Bands[0].Override.RowAppearance.BackGradientStyle = Infragistics.Win.GradientStyle.Vertical;
MyControl has a transparent background, and the performance is terrible (scrolling is laggy, resizing the grid takes up to 5 seconds, etc.). If I switch MyControl's backcolor to a plaincolor (eg white), the performance is smooth again.
I've found the performance bottleneck seems to be MyControl's OnPaintBackground method : It seems to be called a ridiculous number of time. Entering a cell results in 3 calls, as does leaving a cell ; scrolling just one row down leads to 3-4 calls to OnPaintBackground for every visible cell, while I would have excepted only one call to the newly visible cell.
Overriding this method and doing nothing in it results in smooth performance, but I've got some visual artefacts here and there, so this doesn't seem to be a viable option.
I've also considered using an ultrapanel as MyControl's background, and applying it the same kind of gradient as the grid does, but It's a nightmare to keep the gradient in sync with the current row (which can be selected, or highlighted, etc.)
Is there something I can do to optimize this ? Is this a known issue ?
Hi,
The way the ControlContainerEditor work is that it has to set the Value on your control and force it to paint every time a cell in the grid paints. For a transparent control, it has to make sure that when your control paints, it paints itself onto a surface that correctly represents what would be underneath it.
So if you scroll the grid, it has to paint at least once for every visible cell.
I'm not entirely sure why it's painting multiple times when a cell enters edit mode - that could be a bug.
Can you post a small sample project demonstrating these issues so we can check it out? It's possible that maybe our code is not as efficient as it could be and we could try to improve it.
Here is a sample ; each time onpaintbackground is called on my UserControl, it just prints the corresponding row number in the textbox on the program form.
You can notice that :
- when the mouse pointer passes over a cell of the MonitoredColumn (without clicking) and leaves it, there's 4 total calls to the OnPaintBackground method.
- If you resize the grid size (using the horizontal splitter) to show a verical scrolling bar, scroll all the way to the bottom of the grid, and then click the "down" arrow at the bottom of the scrollbar, you'll see all the cells of the MonitoredColumn are repainted twice. I would have expected nothing to happen.
- a resizing of the grid also result in a repainting of all cells twice instead of one.
- a resizing of the k column (which doesn't event touches the MonitoredColumn results of two calls on each cell of the MonitoredColumn