| Groups | Blog | Home |
dotnet drawing api : Is GDI+ appropriate for...
I am looking to create a CAD type interface (primarily 2D/2.5D). My desired development platform is VB.Net. Is GDI+ appropriate for creating and manipulating bitmaps in a fast manner? I will create a control/class/application that will compose the view. The end consumer of the view could be any of the following: 1. Fully interactive desktop application. 2. Output directly to file. 3. Send streams or files to client web browser. If the target interface is a desktop application, then it will need to smoothly support dynamics and mouse input. I'm fairly certain I will end up creating a custom user control for this. For web delivery, the application/service could possibly be feeding hundreds of clients, so it needs to be somewhat speedy. Basically, my thinking is it would be faster to render the current display area to a bitmap, and then display the resulting bitmap as an Image or stream it out to the appropriate client instead of trying to render on-screen. I'm also making an assumption that this would be more friendly with dynamics. DirectX "might" be the way to go for the desktop, but it really doesn't work the way I want it to. Any 3D I do would be more parametric instead of tri-vertex polygons or polyface meshes. And in the end, DirectX just seems like too much overhead and work to get what I really want. I also desire to keep the control/class as lightweight as possible. Due to the nature of how I think this will work, I suspect I will need access to and render things pixel by pixel, especially if I end up implementing transparency and such. However, I just don't know if GetPixel/SetPixel etc. in GDI+ is an efficient way to go. So do ya'll really think that GDI+ would be appropriate or should I consider some third party stuff? Any other comments and/or suggestions? Thanks, Gerald
I should make a correction here.
After some consideration, I suppose the question is really not about GDI+ but more about the BitMap Object. Although GDI+ and the Graphics Object will be a huge part of it when it comes to implementing the desktop interface. Well, ok they are all intertwined, but I hope you get my meaning. Gerald [quoted text, click to view] "Cablewizard" <Cablewizard@Yahoo.com> wrote in message news:%23PYgQPSaEHA.712@TK2MSFTNGP11.phx.gbl... > I'm a long time programmer, but fairly new to display graphics programming. > I am looking to create a CAD type interface (primarily 2D/2.5D). > My desired development platform is VB.Net. > Is GDI+ appropriate for creating and manipulating bitmaps in a fast manner? > > I will create a control/class/application that will compose the view. > The end consumer of the view could be any of the following: > 1. Fully interactive desktop application. > 2. Output directly to file. > 3. Send streams or files to client web browser. > > If the target interface is a desktop application, then it will need to smoothly > support dynamics and mouse input. I'm fairly certain I will end up creating a > custom user control for this. > For web delivery, the application/service could possibly be feeding hundreds of > clients, so it needs to be somewhat speedy. > Basically, my thinking is it would be faster to render the current display area > to a bitmap, and then display the resulting bitmap as an Image or stream it out > to the appropriate client instead of trying to render on-screen. I'm also making > an assumption that this would be more friendly with dynamics. > > DirectX "might" be the way to go for the desktop, but it really doesn't work the > way I want it to. Any 3D I do would be more parametric instead of tri-vertex > polygons or polyface meshes. And in the end, DirectX just seems like too much > overhead and work to get what I really want. I also desire to keep the > control/class as lightweight as possible. > > Due to the nature of how I think this will work, I suspect I will need access to > and render things pixel by pixel, especially if I end up implementing > transparency and such. However, I just don't know if GetPixel/SetPixel etc. in > GDI+ is an efficient way to go. > > So do ya'll really think that GDI+ would be appropriate or should I consider > some third party stuff? > Any other comments and/or suggestions? > > Thanks, > Gerald > >
It is much faster to render on the client, and more scalable. VG.net can
render in IE, if you wish. Regards, Frank Hileman check out VG.net: www.vgdotnet.com Animated vector graphics system Integrated Visual Studio .NET graphics editor [quoted text, click to view] "Cablewizard" <Cablewizard@Yahoo.com> wrote in message news:%23PYgQPSaEHA.712@TK2MSFTNGP11.phx.gbl... > I'm a long time programmer, but fairly new to display graphics programming. > I am looking to create a CAD type interface (primarily 2D/2.5D). > My desired development platform is VB.Net. > Is GDI+ appropriate for creating and manipulating bitmaps in a fast manner? > > I will create a control/class/application that will compose the view. > The end consumer of the view could be any of the following: > 1. Fully interactive desktop application. > 2. Output directly to file. > 3. Send streams or files to client web browser. > > If the target interface is a desktop application, then it will need to smoothly > support dynamics and mouse input. I'm fairly certain I will end up creating a > custom user control for this. > For web delivery, the application/service could possibly be feeding hundreds of > clients, so it needs to be somewhat speedy. > Basically, my thinking is it would be faster to render the current display area > to a bitmap, and then display the resulting bitmap as an Image or stream it out > to the appropriate client instead of trying to render on-screen. I'm also making > an assumption that this would be more friendly with dynamics. > > DirectX "might" be the way to go for the desktop, but it really doesn't work the > way I want it to. Any 3D I do would be more parametric instead of tri-vertex > polygons or polyface meshes. And in the end, DirectX just seems like too much > overhead and work to get what I really want. I also desire to keep the > control/class as lightweight as possible. > > Due to the nature of how I think this will work, I suspect I will need access to > and render things pixel by pixel, especially if I end up implementing > transparency and such. However, I just don't know if GetPixel/SetPixel etc. in > GDI+ is an efficient way to go. > > So do ya'll really think that GDI+ would be appropriate or should I consider > some third party stuff? > Any other comments and/or suggestions? > > Thanks, > Gerald > >
James,
Thanks for the response. The normal response once people see the VB.Net is to call me stupid and tell me how this can only be done in C++ and/or Java. Glad to see I haven't heard that here. additional comments below... [quoted text, click to view] > For interactive you need a client side application. My advice is to ignore > GDI+ double buffering and draw on a Bitmap. For a client app this can be > drawn to the screen, for a web user this can be converted to JPEG/PNG etc (I > recommend PNG) and streamed to the browser. The performance of GDI+ is > quite acceptable with a Bitmap created 32 bit pargb. It is pretty much a given that interactive graphics needs a client side application. For the web stuff, it is going to be limited to view only, with support for pan/zoom/etc. It was my thought that drawing to the Bitmap would be best, glad to hear you concur. Web graphics would be PNG. JPEG is insufficient for Vector graphics, too fuzzy. Would it be much faster to render the Bitmap in memory directly and then display the resulting Bitmap than to use the Graphics object to "draw" the picture in memory? [quoted text, click to view] > An addiitonal option is to write SVG code for the web client. The GDI > graphicspath construct can be converted to an SVG definition quite easily. > You get much lower bandwidth requirements but it is more work and the client > will need an SVG plugin. I had read the spec for SVG a long time ago, back when they called it "Stylable Vector Graphics". Not sure when they started calling it "Scalable" instead. However, I think Scalable and Vector are somewhat redundant. And one of the big points is that they proposed it be Stylable on the client side, which would not have been good for this. I will need to revisit the new specs. The issue with that is that what I need to display is not like the typical single file CAD type stuff. Otherwise I could just use one of the dozen or so commercial products already out there. I'm really building a "GIS Emulator", where the data is stored in various CAD formats and tiled by map areas. This means I'm dealing with tens of thousands of underlying map tiles in some cases. As the user changes view perpective, the actual data to be displayed needs to be composed from these underlying maps. Vector on the web client is great if you are zoomed in tightly in an area. But as they zoom out, you quickly reach a point of diminishing returns as the vector element cache can quickly become huge. So I am thinking that if I stream the resulting rendered image, then user will get more of a consistent experience regardless of zoom ratio. Also, (my logic may be flawed here) but since the underlying elements already have the necessary info to render themselves, it seems kind of redundant to convert to GDI GraphicsPaths and/or SVG. But like I said, I am fairly new to the graphics programming side, so hopefully I can count on the real world experience of those who have done it instead of wasting my time trying to test the various implementation options. Any more advice? Thanks, Gerald
Thanks James.
Been looking into it all. Sounds like passing a general Graphics object into the class and have it render to whatever might be the way to go. Guess I'll have to try the drawing using Graphics vs Get/SetPixel in the BitMap to see which is best. I am well versed in matrices, vectors, element stroking, etc. so transforms aren't a problem. The math is the easy part, presenting the results to the user can be frustrating :-) Thanks again for the input. Gerald [quoted text, click to view] "James Westgate" <james.westgate@nospamcrainiate.com> wrote in message news:erzIJ%23aaEHA.1000@TK2MSFTNGP12.phx.gbl... > Hi, > > You'll see when you get into GDI+ that you can draw to a bitmap or > directly to a form/usercontrol, it all comes down to using the > graphics object, which is nice. If you understand the graphics, pen, > solidbrush, graphicspath and bitmap classes then you are well on your > way. The rest is just filling in the blanks. If you havent done any > graphics programming before I really suggest you get your head around > transforms as well, they can be especially helpful. > > Bob Powell also has a FAQ with a lot of good advuce, you can read > this at > > http://www.bobpowell.net/ > > James > > Create interactive diagrams and flowcharts with ERM Diagram at > > http://www.crainiate.net > > Take the ERM Tour at http://www.flowchartcontrol.com > -- > Composed with Newz Crawler 1.7 http://www.newzcrawler.com/
Hi Gerald,
For interactive you need a client side application. My advice is to ignore GDI+ double buffering and draw on a Bitmap. For a client app this can be drawn to the screen, for a web user this can be converted to JPEG/PNG etc (I recommend PNG) and streamed to the browser. The performance of GDI+ is quite acceptable with a Bitmap created 32 bit pargb. An addiitonal option is to write SVG code for the web client. The GDI graphicspath construct can be converted to an SVG definition quite easily. You get much lower bandwidth requirements but it is more work and the client will need an SVG plugin. James -- Create interactive diagrams and flowcharts with ERM Diagram at http://www.crainiate.net Take the ERM Tour at http://www.flowchartcontrol.com [quoted text, click to view] "Cablewizard" <Cablewizard@Yahoo.com> wrote in message news:%23PYgQPSaEHA.712@TK2MSFTNGP11.phx.gbl... > I'm a long time programmer, but fairly new to display graphics programming. > I am looking to create a CAD type interface (primarily 2D/2.5D). > My desired development platform is VB.Net. > Is GDI+ appropriate for creating and manipulating bitmaps in a fast manner? > > I will create a control/class/application that will compose the view. > The end consumer of the view could be any of the following: > 1. Fully interactive desktop application. > 2. Output directly to file. > 3. Send streams or files to client web browser. > > If the target interface is a desktop application, then it will need to smoothly > support dynamics and mouse input. I'm fairly certain I will end up creating a > custom user control for this. > For web delivery, the application/service could possibly be feeding hundreds of > clients, so it needs to be somewhat speedy. > Basically, my thinking is it would be faster to render the current display area > to a bitmap, and then display the resulting bitmap as an Image or stream it out > to the appropriate client instead of trying to render on-screen. I'm also making > an assumption that this would be more friendly with dynamics. > > DirectX "might" be the way to go for the desktop, but it really doesn't work the > way I want it to. Any 3D I do would be more parametric instead of tri-vertex > polygons or polyface meshes. And in the end, DirectX just seems like too much > overhead and work to get what I really want. I also desire to keep the > control/class as lightweight as possible. > > Due to the nature of how I think this will work, I suspect I will need access to > and render things pixel by pixel, especially if I end up implementing > transparency and such. However, I just don't know if GetPixel/SetPixel etc. in > GDI+ is an efficient way to go. > > So do ya'll really think that GDI+ would be appropriate or should I consider > some third party stuff? > Any other comments and/or suggestions? > > Thanks, > Gerald > >
Gerald,
In addition to Bob Powell's site. I find both Charles Petzold's "Programming Microsoft Windows with Microsoft Visual Basic .NET" from MS Press and Chris Sells' "Windows Forms Programming in C#" provide a wealth of information on both GDI+ programming as well as Windows Forms programming. Hope this helps Jay [quoted text, click to view] "Cablewizard" <Cablewizard@Yahoo.com> wrote in message news:%23KWEy1aaEHA.596@TK2MSFTNGP11.phx.gbl... > James, > > Thanks for the response. The normal response once people see the VB.Net is to > call me stupid and tell me how this can only be done in C++ and/or Java. Glad to > see I haven't heard that here. additional comments below... > > For interactive you need a client side application. My advice is to ignore > > GDI+ double buffering and draw on a Bitmap. For a client app this can be > > drawn to the screen, for a web user this can be converted to JPEG/PNG etc (I > > recommend PNG) and streamed to the browser. The performance of GDI+ is > > quite acceptable with a Bitmap created 32 bit pargb. > > It is pretty much a given that interactive graphics needs a client side > application. > For the web stuff, it is going to be limited to view only, with support for > pan/zoom/etc. > It was my thought that drawing to the Bitmap would be best, glad to hear you > concur. > Web graphics would be PNG. JPEG is insufficient for Vector graphics, too fuzzy. > Would it be much faster to render the Bitmap in memory directly and then display > the resulting Bitmap than to use the Graphics object to "draw" the picture in > memory? > > > An addiitonal option is to write SVG code for the web client. The GDI > > graphicspath construct can be converted to an SVG definition quite easily. > > You get much lower bandwidth requirements but it is more work and the client > > will need an SVG plugin. > > I had read the spec for SVG a long time ago, back when they called it "Stylable > Vector Graphics". Not sure when they started calling it "Scalable" instead. > However, I think Scalable and Vector are somewhat redundant. And one of the big > points is that they proposed it be Stylable on the client side, which would not > have been good for this. I will need to revisit the new specs. > > The issue with that is that what I need to display is not like the typical > single file CAD type stuff. Otherwise I could just use one of the dozen or so > commercial products already out there. I'm really building a "GIS Emulator", > where the data is stored in various CAD formats and tiled by map areas. This > means I'm dealing with tens of thousands of underlying map tiles in some cases. > As the user changes view perpective, the actual data to be displayed needs to be > composed from these underlying maps. > > Vector on the web client is great if you are zoomed in tightly in an area. But > as they zoom out, you quickly reach a point of diminishing returns as the vector > element cache can quickly become huge. So I am thinking that if I stream the > resulting rendered image, then user will get more of a consistent experience > regardless of zoom ratio. Also, (my logic may be flawed here) but since the > underlying elements already have the necessary info to render themselves, it > seems kind of redundant to convert to GDI GraphicsPaths and/or SVG. > > But like I said, I am fairly new to the graphics programming side, so hopefully > I can count on the real world experience of those who have done it instead of > wasting my time trying to test the various implementation options. > > Any more advice? > > Thanks, > Gerald > >
Hi,
You'll see when you get into GDI+ that you can draw to a bitmap or directly to a form/usercontrol, it all comes down to using the graphics object, which is nice. If you understand the graphics, pen, solidbrush, graphicspath and bitmap classes then you are well on your way. The rest is just filling in the blanks. If you havent done any graphics programming before I really suggest you get your head around transforms as well, they can be especially helpful. Bob Powell also has a FAQ with a lot of good advuce, you can read this at http://www.bobpowell.net/ James Create interactive diagrams and flowcharts with ERM Diagram at http://www.crainiate.net Take the ERM Tour at http://www.flowchartcontrol.com --
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |