Community
Participate
Working Groups
DiagramOutlinePage has an overview page which converts the current diagram into an Image which is then drawn to the page. This image is created by getting the same root figure that the big editor uses and asking it to paint to a scaled graphic context assigned to an image. Because it's using the same figures as the main editor all the detail of the main editor shows in the image. But when the diagram gets big or is filled with lots of text, the editor really slows down creating figures so small that the user can't see its details anyway. Ironically the bigger the diagram the more a user would want to use the overview figure to navigate the diagram, but the worst the performance of overview. Perhaps the figures that overview uses to create its image should be a separate set of rectangle figures derived from the original figures w/o text or inner content. At the very least perhaps the text shouldn't be drawn-- YourKit shows a lot of time spent scaling the font for these figures.
Perhaps DiagramOutlinePage wouldn't have to change if some paint methods didn't paint when the scaling was too small: 1) If scaling falls below 75%, don't draw any children of the decorator layers (too small to see anyways) 2) if scaling is below 50%, don't draw anything in a list compartment (perhaps draw a gray rectangle instead) 3) if scaling is below 25% don't draw connections the scaling can be found from ScaledGraphics#getAbsoluteScale() This would apply to the editor and any contents in the DiagramOutlinePage. If DiagramOutlinePage is showing a large diagram, only the outlines of the main diagram views would be painted which would be a lot faster then trying to paint details the user can't see anyways.
[GMF Restructure] Bug 319140 : product GMF and component Runtime was the original product and component for this bug
