Object Oriented Graphics issue
-
Sorry for the long post, but please bear with me. I have a graphics user control that can display several graphics primitives, plus bitmaps and text in 2D. Users can easily scroll/pan/zoom, select objects and scale or move them, and is used all over my organization (for a visual, one of the uses is to overlay CAD information on top of a bitmap). The graphics objects are also used outside of the context of drawing - some applications only use the objects themselves to do calculations for other purposes. Each object implements an interface and most manipulation of the object is through that interface. Each object draws itself using a supplied System.Drawing.Graphics object like a ton of articles on code project and elsewhere suggest. The current design works great for collections of graphics objects up to about 3,000 or so, but now the control is being used in situations where there may be 30k+ objects in the drawing and performance is very poor. I've been going over the code and looking for optimizations, and there are several things I'm going to work on, but one of the things I also want to try is using different graphics for drawing, perhaps Managed DirectX, but here lies a problem. The interface that each object implements includes 3 methods that need a System.Drawing.Graphics object as a parameter. One of the methods is Draw(), the other two are for determining the size of a shape (which is really only needed for text objects - ie. MeasureString - but had to be in the interface to keep things generic). So basically, I need a way to decouple the actual drawing method used from the object itself. One idea I had was to create a separate GraphicsContext object that would be passed into the objects in place of System.Drawing.Graphics and would have methods similar to System.Drawing.Graphics, but could be implemented behind the scenes in whatever way I wanted. The problem with that is I'm simply coupling to something else - and the users who don't even use the objects as "graphics" have yet another thing to use for determining size (unless I can figure out a way to measure a string without some type of graphics). Maybe I'm just over-thinking this one. Another idea I had is to completely remove the graphics requirement for all methods and remove the Draw method entirely, then only the drawing code itself would be coupled to a specific method. This has worse problems though - users can currently add their own graphics objects, but this method would not know how to draw those. Plus the performan
-
Sorry for the long post, but please bear with me. I have a graphics user control that can display several graphics primitives, plus bitmaps and text in 2D. Users can easily scroll/pan/zoom, select objects and scale or move them, and is used all over my organization (for a visual, one of the uses is to overlay CAD information on top of a bitmap). The graphics objects are also used outside of the context of drawing - some applications only use the objects themselves to do calculations for other purposes. Each object implements an interface and most manipulation of the object is through that interface. Each object draws itself using a supplied System.Drawing.Graphics object like a ton of articles on code project and elsewhere suggest. The current design works great for collections of graphics objects up to about 3,000 or so, but now the control is being used in situations where there may be 30k+ objects in the drawing and performance is very poor. I've been going over the code and looking for optimizations, and there are several things I'm going to work on, but one of the things I also want to try is using different graphics for drawing, perhaps Managed DirectX, but here lies a problem. The interface that each object implements includes 3 methods that need a System.Drawing.Graphics object as a parameter. One of the methods is Draw(), the other two are for determining the size of a shape (which is really only needed for text objects - ie. MeasureString - but had to be in the interface to keep things generic). So basically, I need a way to decouple the actual drawing method used from the object itself. One idea I had was to create a separate GraphicsContext object that would be passed into the objects in place of System.Drawing.Graphics and would have methods similar to System.Drawing.Graphics, but could be implemented behind the scenes in whatever way I wanted. The problem with that is I'm simply coupling to something else - and the users who don't even use the objects as "graphics" have yet another thing to use for determining size (unless I can figure out a way to measure a string without some type of graphics). Maybe I'm just over-thinking this one. Another idea I had is to completely remove the graphics requirement for all methods and remove the Draw method entirely, then only the drawing code itself would be coupled to a specific method. This has worse problems though - users can currently add their own graphics objects, but this method would not know how to draw those. Plus the performan
How about something like a
PrimitiveInformationmember for each object which basically contains polygon, color and type information? (Something like a Vector4 struct). This would allow for a parameterlessDrawfunction. Instead, each renderer (DirectX, OpenGL, System.Drawing) would just pull the PrimitiveInformation and Draw it the way it does. DX, OpenGL and System.Drawing all can easily parse basic information like polygons, colors etc. Something like this:interface IDrawableObject
{
// implement as attributes
ObjType type; // CIRCLE, RECT, LINE etc
Vector4[] polygons; // x, y, z, color
Vector3 translation;
Vector3 rotation;public void Draw() { ... }}
This could be easily used with any renderer. regards
-
Sorry for the long post, but please bear with me. I have a graphics user control that can display several graphics primitives, plus bitmaps and text in 2D. Users can easily scroll/pan/zoom, select objects and scale or move them, and is used all over my organization (for a visual, one of the uses is to overlay CAD information on top of a bitmap). The graphics objects are also used outside of the context of drawing - some applications only use the objects themselves to do calculations for other purposes. Each object implements an interface and most manipulation of the object is through that interface. Each object draws itself using a supplied System.Drawing.Graphics object like a ton of articles on code project and elsewhere suggest. The current design works great for collections of graphics objects up to about 3,000 or so, but now the control is being used in situations where there may be 30k+ objects in the drawing and performance is very poor. I've been going over the code and looking for optimizations, and there are several things I'm going to work on, but one of the things I also want to try is using different graphics for drawing, perhaps Managed DirectX, but here lies a problem. The interface that each object implements includes 3 methods that need a System.Drawing.Graphics object as a parameter. One of the methods is Draw(), the other two are for determining the size of a shape (which is really only needed for text objects - ie. MeasureString - but had to be in the interface to keep things generic). So basically, I need a way to decouple the actual drawing method used from the object itself. One idea I had was to create a separate GraphicsContext object that would be passed into the objects in place of System.Drawing.Graphics and would have methods similar to System.Drawing.Graphics, but could be implemented behind the scenes in whatever way I wanted. The problem with that is I'm simply coupling to something else - and the users who don't even use the objects as "graphics" have yet another thing to use for determining size (unless I can figure out a way to measure a string without some type of graphics). Maybe I'm just over-thinking this one. Another idea I had is to completely remove the graphics requirement for all methods and remove the Draw method entirely, then only the drawing code itself would be coupled to a specific method. This has worse problems though - users can currently add their own graphics objects, but this method would not know how to draw those. Plus the performan
You need to see Adapter design pattern. It helps you work with two different interfaces (system.drawing and directx) which is not otherwise possible because of incompatible interfaces. For more information about adapter design pattern click here. http://www.dofactory.com/Patterns/PatternAdapter.aspx[^]
M Aamir Maniar aamirOnline.com
-
You need to see Adapter design pattern. It helps you work with two different interfaces (system.drawing and directx) which is not otherwise possible because of incompatible interfaces. For more information about adapter design pattern click here. http://www.dofactory.com/Patterns/PatternAdapter.aspx[^]
M Aamir Maniar aamirOnline.com
It took me a while to figure out how I could apply this, but I think I have it now. It's basically what I was thinking already, but one step forward so that the user doesn't need to worry about the graphics at all, it will be done fully inside the object. Thanks a bunch.
----- In the land of the blind, the one eyed man is king.