I have noticed a perfromance problem with the painting of the DOTS when when the UserGridStyle property is set to <span =“highlight”>GoViewGridStyle.Dots.
When the dots are spaced fairly close together (about 1/8" on my screen), the goView paints very slowly. You can see this by dragging another window over the goView (especially if the other window is in the same application – same message pump?) – everything slows down and the dragging goes very slowly.
Other than turning of DOTS, is there any way to improve this performance?
I just tried this in Demo1 and found that the performance was pretty good. I couldn’t really tell that it was slower when the GridCellSize is 5x5 pixels. I tried dragging GoObjects around the view as well as other windows, both from the same application and different applications.
So you had tried your application with and without the visible grid? Perhaps there's something else that is slower than you would like, such as when there are many or large images.
Ah, yes, I see it, but for me on my machine, it’s subtle.
But even on slow machines, I don't think you are going to be able to reduce the application start time by a noticeable amount by turning off the grid. Dragging around occluding windows causes a lot of painting to happen very often. Opening a window causes painting to happen just once, when drawing the whole view.
Hi. I have a 3Ghz DUO with Nvidia (not sure which), too. Our app is more noticeable than the demo – I don’t know why yet.
Our app does a bunch of resizing of panels at startup (which forces repaints), and everything seems to be getting invalidated. So we end up repainting a lot (not caused by the goDiagram, I should mention).
So I am just removing issues one at a time, and I noticed the DOTS had some effect.
So it may be nothing, but it does seem that having the DOTS make the paint a lot slower. Compared to just having shapes.
Yes, it’s true that if there are going to be resizes of the GoView control, or if there are other changes which cause scrollbars to appear or disappear, it will invalidate the whole control.
If you want to optimize out the painting during this initialization process, you can call GoView.BeginUpdate() followed by GoView.EndUpdate().
Even better, call GoDocument.BeginUpdateViews() followed by GoDocument.EndUpdateViews(), which automatically calls the corresponding GoView methods on all GoViews that are displaying the given document.
As a reminder to all who might read this post -- don't perform unnecessary "optimizations"! Improper or premature optimizations are a leading cause of bugs. Only do this kind of optimization when you can prove that there is a significant improvement, and that you are correctly implementing such optimization.
That's why we tell people not to set any "SuspendsUpdates" property, even though it's available. I think calling BeginUpdate/EndUpdate is safer than setting SuspendsUpdates, but you still need to make sure the calls are always paired up (use try/finally!) and only called when you are sure it's worth it.
Well, on this machine, which is a 3GHz single processor with Nvidia 5200 and 1GB memory, I really have a hard time telling the difference in behavior when dragging an object around quickly, with or without GoView.GridStyle == GoViewGridStyle.Dot. I’m running the unmodified Demo1.exe for .NET 2.0.
Maybe there's some other reason for the performance difference.
Maybe there’s some other reason for the performance difference.
Oops, I think the demo is ok. The demo is only slow if the properties window is open while you drag. :)
I guess I’m not sure what’s making my app slow in the case of dragging with the GRID dots. Will keep looking.