GDI, CDC, MFC.. Intuitive graphic programming nonexistant here?

OK. I must admit I'm very frustrated now. I need to add to my existing MFC program, a small window to draw graphics into. Just a basic nxm array of pixels on which I can plot data points retreived from my already working hardware system.

You would think that in the age of totally graphic interfaces, this would be super easy. But It seems that everyone writing code tutorials for windows MFC is concerned with packing in technical jargon to the point of utter loss of anything resembling intuitive tutorial. Rigorous descriptions of inheritance and member functions do little to help me figure out how to get a very basic implementation going.

Example: http://www.samspublishing.com/librar...seqNum=67&rl=1

I realize the power of CDC stuff, but .. - I hate having to use a space shuttle factory to build a skateboard.

Check out the Scribble sample.

http://msdn2.microsoft.com/en-us/lib...ts(VS.80).aspx

It may be a good starting point for you, and you may also be able to lift portions of it wholesale to make it easier.

It's important you don't take it too lightly, though, because it's extremely easy to introduce memory leaks and other ugly stuff using GDI.

Well, unfortunately, using the DC is actually the simplest way to present graphics in Windows. Other options are like genetic engineering, to take your analogy further :)

In fact, the DC is the only way you're going to display graphic content of your own creation.

This is because Windows is an event driven system, and drawing is generally handled in the context of an event (the paint event), and the device context is something like an open handle to a file or device in Linux.

The scribble example is a good idea. However, consider this quick 'n dirty (and entirely unchecked/untested) attempt..

Code:

---


void SomeWin::OnPaint()
{
 CPaintDC dc( this );

 dc.MoveTo( 10,10 );
 dc.LineTo( 15,20 );
 dc.LineTo( 20, 10 );

}

---

Since Y is 'reversed' from standard graphing, this would create (I think) something resembling a V.

That's not particularly complicated, but of course it uses only the default color. Selecting a pen of a chosen color might make more sense, and scribble goes through some of that.

At this point I'm personally accustomed to the concept of the device context, so I find it fairly simple. I don't use MFC much (I often use WxWidgets, which is fairly good, cross platform framework, and in many ways is a little easier to write with, but not much different in the sense that it also is based on a device context).

The only other option open to you, if you call it an option, is to write directly to a bitmap that you can blit to the display when you get it 'finished'. That's actually a good technique to avoid flicker. Unfortunately, in order to blit the resulting bitmap onto the display, you must use a device context.

What are you attempting to graph? That might help me direct you to specific uses of the DC to simplify your work.

Thanks for the suggestions. You both made good points that helped me out. I'm glad to know I'm not the only one out there who finds this stuff a bit "obtuse" to grasp.

After reading your suggestions, I came up with this method for creating and updating a "drawing window". A custom class, extending CStatic:

Code:

---

//Custom class "CPict"
void CPict::OnPaint()
{
CPaintDC dc(this);


if(hasimage==true){
  for(int i=0;i<320;i++){
        for(int j=0;j<256;j++){
                  grey=image[(1280-i*4)+((1024-j*4)*1280)];
         
                dc.SetPixel(i,j,RGB(grey,grey,grey));

  }}       
}

}


// I call this whenever I need to display the newly created image.
void CPict::OnDrawVideo(unsigned char *inputImage, int top, int bottom, int left, int right){
CPaintDC dc(this);

  hasimage=true;
  for(int i=0;i<1280*1024;i++){
                image[i]=inputImage[i];
  }
 Invalidate();
 UpdateWindow();
}

---

This method is very slow to draw.
Now, I wonder how much the method of creating a memory DC for blitting would speed this up...

Thanks again

Code:

---

for(int i=0;i<1280*1024;i++)
{
  image[i]=inputImage[i];
}

---

Why copy byte by byte ??? copy the entire block at once.

Code:

---

memcpy (image, inputimage, 1280*1024);

---

Quote:

---

Now, I wonder how much the method of creating a memory DC for blitting would speed this up...

---

dc.SetPixel slows you down . . So using a memory DC in combination with SetPixel still would be slow (yes . .there are better ways instead of using SetPixel but I don't know them)

There's huge potential for performance gain.


SetPixel is your primary bottleneck here.

You'll find tremendous improvement by using a bitmap you can manipulate yourself. It's a bit nastier - C like to do, but ya gotta do what ya gotta do...

You'll also get some (perhaps more than a little) speed bump by sequencing a pointer through the image array, rather than calculating the offset every time.

I'd recommend considering something like ImageMagick, CxImage or whatever you find that you like, such that you can gain access to a buffer of RAM you can manipulate as image data, for the creation of your plots.

You're approaching an 'optimization' step that hinges on a design step, a rather unique position. Usually we say "design and debug first, then optimize", but we also contend that a better algorithm choice is more effect at performance than optimization.

Here, you're facing both at the same time. The best algorithmic approach to setting individual pixels is direct access to the memory of an image, which isn't all that difficult once you get the hang of it, and you're almost there in this code anyway.

If you can dictate the display format, you can force a situation where the pixel is a 3 or 4 byte RGB like you'd expect, and setting the pixel color is as simple as you'd expect.

Look at the source of any code you have that sets a pixel on an image that can be blitted to the display. CxImage has it, ImageMagick does (but the code might be a little tough to follow) - I think WxWidget's wxImage source code gives a good, simple example.

Quote:

---

Originally Posted by Skizmo

Why copy byte by byte ??? copy the entire block at once.

---

Why indeed! I changed that, thanks.

JVene, yes I think I will impliment something like that. What you are referring to is a DIB, right? I've been reading about those. Seems like just what I need to do, and in fact the library I'm working with on the other end to help create the initial image can output a Bitmap, so maybe I can plug it straight in.

I've been in the Java/XCode world for a few years now, but this stuff is slowly coming together for me. Thanks for your attention everyone, there is nothing better than a good forum for getting past roadblocks with this stuff.

People who are new to this kind of programming often find it 'unintuitive'. But that's because they're almost always making the same, common mistake. Perhaps most common among all the mistakes that newbies make is that they forget that Windows can run multiple programs as well as theirs. And it's for that reason that Windows can't let you do what you'd naturally like to do - which is to write directly to the screen.

By providing each program with a device context, Windows lets each program think that its writing to the screen, whether it is or it isn't. Windows then decides what actually gets shown on the screen. If some other program was partially obscuring yours, this would be a combination of part of your program's output and part of the other program's. The use of device contexts might seem unintuitive - but it ensures that users see something sensible, instead of the chaos that would ensue from each program assuming it's the most important one. Multitasking could never work if programs were allowed to access the hardware directly.

Hi John E, thanks for your thoughts.

In fact, you illustrate exactly what I'm talking about (or lack thereof). My complaint was not so much about the unintuitiveness (is that a word?) of the code itself, but toward the resources out there supposedly oriented towards beginners such as myself.

I would have liked to have seen a tutorial that begins like you did, by explaining the theory of how it is going to proceed. Then, it would give an example of a "hello world" graphics program, just a simple program to demonstrate how to set up an object to draw in, and to draw a few pixels. Nothing more.

The scribble example was OK, but included too much "stuff". Examples like that are hard for the beginner, because they confuse the learner as to which parts are "Scribble-specific" and which parts are core to the goal of simply learning to make dots on the screen!

I have learned a lot by now (2 weeks later) thanks to this thread, and the suggestions inside. Thanks guys! And John E, maybe you can write the tutorial I'm imagining, for the next one of my kind! :-D


edit: PS, yes I came from an oldskool mode 13h write-to-video-mem mindset :)

Quote:

---

yes I came from an oldskool mode 13h write-to-video-mem mindset

---

hmm. . ... the good old days ;)

Quote:

---

Originally Posted by typewriter

The scribble example was OK, but included too much "stuff". Examples like that are hard for the beginner, because they confuse the learner as to which parts are "Scribble-specific" and which parts are core to the goal of simply learning to make dots on the screen!

---

Very true. You'd think that the writers of these books / tutorials would realize this. And theres so many tutorials like this--so annoying.

FWIW, Charles Petzold's books explain things in almost the exact manner Typewriter suggested. Highly recommended if you are looking for a comprehensive but comprehensible introduction.