Need help implementing GDI drawing in .net

[qmp]

I have much experience with GDI and VB6.. I have read about the slow performance of GDI+ and do not even want to attempt that. I want to implement GDI in .net.. I have a lot of source regarding the creation of a dhc and such but I am still kind of confused..

So, I want to start with the basics..

Id like to create a picturebox?? .. or at least some sort of region... and for starters, lets just paint it all black .. Lets say I paint it by pressing a button on the form.. button executes the rect() fn to paint the square black..

Now, when I move the form off screen and back on, that paint is now gone? What is the solution for that? How do I implement that? Any examples you can lead me to?

I assume once I have this basic buffering step taking care of, the drawing/updating task of completing this project will be fairly simple.

Basically, I want to draw a meter... part of it is a filled rectangle, and then the other part is a numeric printout.. That stuff should be easy.. But making it stay visible when the user moves the form out of view and back on is confusing me.


Thanks.

 

[IngisKahn]

You either need to repaint the whole control on the Paint event or use a back buffer and blit the invalidated region (the Paint event tells you what region was invalidated).
And why are you hating on GDI+? Its merely a wrapper around GDI and implemented properly youll see similar performance. Plus using GDI+ your app will be portable.

 

[snarfblam]

Its merely a wrapper around GDI

I am pretty sure that this is not true. As far as I know, GDI+ is a whole new library. It many includes new features such as alpha blending, antialiasing, and image resizing/interpolation.

implemented properly youll see similar performance

From my experience this isnt true. I have not tested vector graphics and text rendering, but with image blitting, GDI+ is actually notably slower.

Plus using GDI+ your app will be portable.

This is true, and it should be kept in mind, but portability isnt always an issue or a priority.

All that said, gmp, I think GDI+ would suit for your needs just fine. It is slower, but it does not crawl. I have made many applications, including a few simple games, where GDI+ was used and worked fine. If you want to persist an image to a picturebox, this is the method I recommend: create a Bitmap object where you will draw, assign it to a PictureBoxs Image property, and use the Graphics.FromImage method to create a Graphics object that can be used to edit the Bitmap. When you modify the Bitmap, changes can be presented to the user through the PictureBox.Invalidate method.

[VB]
Dim bmpMeter As New Bitmap(100, 100)
Use the methods of gMeter to render the image
Dim gMeter As Graphics = Graphics.FromImage(bmpMeter)
This line must be executed after the picturebox is created
picMeter.Image = bmpMeter
Update the image like so:
picMeter.Invalidate()
[/VB]

 

[IngisKahn]

That hasnt been my experience.

As its name suggests, GDI+ is the successor to Windows Graphics Device Interface (GDI), the graphics device interface included with earlier versions of Windows. Windows XP or Windows Server 2003 supports GDI for compatibility with existing applications, but programmers of new applications should use GDI+ for all their graphics needs because GDI+ optimizes many of the capabilities of GDI and also provides additional features.

 

[snarfblam]

What hasnt been your experience? The performance difference? Just set up a quick benchmark app. I made an application that drew level screens out of 16x16 tiles in a 16x11 grid. As you navigated the map in VB6 with GDI, the screens seemed to appear instantly. When I ported to VB.Net and GDI+, you could see the level screens being drawn. It was not as smooth and professional. It was clicky and laggy, and my computer is reasonably fast, 1.5 ghz. I would hate to see how it ran on an older machine.

Other people have told me that GDI+ is faster, but after doing an actual test, were surprised with the results, and conceded that GDI is certainly faster in the realm of bitblts.

This may or may not apply to vector graphics. I dont know, but bitblts are appearently not as optimized in GDI+.

 

[IngisKahn]

As of yet it depends on your system. Since GDI+ is a new technology it is not yet fully implemented to run on the hardware drivers (this is changing, the next release will be on par with GDI). It also depends on what youre doing. The point is if youre doing graphics intensive stuff then use MDX for now.

 

[snarfblam]

I havent looked into the next version of GDI+. I dont see how this depends that much on the system either way, and Ive never heard of a test where GDI+ performed better. Maybe someday that will change. Today, GDI is faster, as long as "what youre doing" is a simple bitblt, and its never going to get slower. We cant make a program today based on standards that are expected to improve later, and this topic is not about which will be faster later, its about finding a solution now.

gmp, I doubt that GDI+ will be unable to meet your needs. If you havent already implemented a GDI solution, give GDI+ a whirl. Its "the way of the future" and you ought to get used to it, better sooner than later, and I think it is easier anyways.

 

[qmp]

I have the GDI solution done perfectly in VB6. Its gone through so many revisions and my current revision is very streamlined..

This is used for real time charting.. so speed is very important to me..

I will try to implement the back buffer solution..

The problem I see with that is every time I draw to the buffer I must invalidate the control which would redraw the entire control.. and that is very innefecient.. I want a way to be able to only have the certain area redrawn .

hmmm.. still confused.

 

[snarfblam]

I have the GDI solution done perfectly in VB6.

So... are you using VB6?

If you are using .Net, you can invalidate only a specified region on a control. The control.Invalidate method has several overloads. Depending on the size of a control, it is very possible that invalidating the entire control would not cost enough performance to be of a concern. If it is about 100x100 or smaller, I wouldnt worry about it, but it sounds like you might be working with something larger.

If you are using VB6, you might consider going to the Xtreme VB Talk boards. There is a link on the front page of this site.

 

[qmp]

I am indeed using .net and am aware of the invalidate overloads.

The charting size is dynamic, as big as the user wants.. so It could be full screen..

Im still unclear as to the approach I must take. I wish there were some samples.

I cant believe all charting in .net is done through GDI+ when performance critical apps could have problems.

There must be some samples somewhere. I find it hard to believe Im the first one doing this.

 

[IngisKahn]

You dont have to redraw the whole control, just whats changed.
Performance critical apps use DirectX.

 

[EFileTahi-A]

qmp, you know what? Skip the use of GDI+ and step straight into DirectX. The time you will spend learning GDI+ will be slightly less then the time youll need to learn DirectX9. Computing 2D graphics with DirectX/Direct3D is truly simple.

"OH NO! Youre going to learn DirectX?! Thats too hard and time consuming!"

Lets end this myth! If I found it easy to learn that means any person on this world can do it.

All you need is a good tutorial manual. If you cant find one cantact me over msn

efiletahi@hotmail.com

 

[Talyrond]

gmp, I dont know what you requirements are for your app, but I would guess that GDI+ is more than adequate. I would recommend checking out this link and the whole site:
http://www.bobpowell.net/manipulate_graphics.htm

Have a look and then decide what approach you want to take

 

[snarfblam]

My two cents about DirectX: Is it worth learning? If you will really benefit from it, yes. Is it as easy as GDI+? Not nearly. It is not incredibly difficult, but GDI+ is very intuitive, and practically self-explanitory. DirectX is worth the extra effort if you need a performance boost, but I do not regret putting off learning DirectX as long as I did. I managed just fine without it until now.

 

[qmp]

I thank you all for your replies..

DirectX is out of the question. I do not doubt that it is more than adequate and is a great graphical method to use..

The reason I want to use GDI is because:
GDI is proven to be faster than GDI+
I am very fluent in GDI and have working solutions built using GDI.

The application is very similar to a sizemomitor (the earthquake meter).. with just a few more lines. Very similar to a lie detector test as well. In full screen mode, on slow machines, I do not think GDI+ will be up to the task.

Plus.. like all of us, Im on a time crunch.

I have found solutions to create a hdc to draw on but have not found any that repaint the area when the area goes off screen/on screen.

Per some of your advice, here is what I am thinking my approach is going to be.

I will have to create a backbuffer to draw on.. and bitblt it to my main buffer which is viewable.. Then, if it goes off screen and on screen, i capture the onpaint event and re-bitblt that area from my backbuffer.

I hope that will do it.

PS. Id like to add as well that I am very fluent in OpenGL and prefer OpenGL over DirectX..

 

[IngisKahn]

Id like to add as well that I am very fluent in OpenGL and prefer OpenGL over DirectX..

Well that wont win you any popularity points here.

If youre commited to GDI for this app then thats the way it has to be, but I would strongly suggest looking into MDX for any future .NET apps.

 

[qmp]

Ok.. so far so good..

In the OnPaint event for your picturebox it will have a e.Region or a rectangle or something (I forget the exact param)... but it will tell you the region that is being invalidated and then with that, you can bitblt that section onto your main image...