Gribble2 - CGribbleWnd goes blitting.

• Download source files - 29 Kb
• Download demo project - 69 Kb

Introduction

Gribble1 outlined the basics of using a CWnd in full screen mode. Gribble2 experiments with the BitBlt and StretchBlt GDI functions, revisits WM_PAINT and WM_ERASEBKGND, and discovers the WM_SYNCPAINT message along the way.

The Gribble2 project

There are a few changes in the mechanics of the Gribble2 CWnd, some of which arise from the desire to do some blitting operations, some just for convenience. Gribble2, like Gribble1, is a stock off the shelf VC6 App Wizard generated MFC based exe project, with no Doc/View support. A Gribble menu item 'Go' is handled in CGribble2App to create the gribble window:

void CGribble2App::OnGribbleGo() 
{
    // TODO: Add your command handler code here
    // Lets create the Gribble window!
    if(!m_wndGribble.m_hWnd) {

        CString csWndClass = AfxRegisterWndClass(CS_OWNDC 
            | CS_BYTEALIGNCLIENT,
            ::LoadCursor(AfxGetInstanceHandle(), 
            MAKEINTRESOURCE(IDC_CURSOR1)),
            (HBRUSH)::GetStockObject(BLACK_BRUSH),
            ::LoadIcon(AfxGetInstanceHandle(), 
            MAKEINTRESOURCE(IDI_G2ICON)));

        if(!(m_wndGribble.CreateEx(WS_EX_LEFT,
            (LPCTSTR)csWndClass,
            "Gribble Window",
            WS_VISIBLE|WS_POPUP,
            0,0,0,0,    
            NULL,
            NULL
            ))) {
                AfxMessageBox(
                    "Failed to Create Gribble Window)");
                return;
            }
    }   
}

As in Gribble1, Gribble2 registers its own window class to provide the OS with information on how windows of this class should be maintained. Again, style of CS_OWNDC is used, and the CS_BYTEALIGNCLIENT style is added - this will help the efficiency of the BitBlt calls later. (At least, thats what the documentation says - in practice, I haven't noticed a difference with or without this, or the CS_BYTEALIGNWINDOW style. It may be that working with a full screen window makes this superfluous.)

Gribble1 maintained its own cursor by loading the resource in its OnCreate method and overriding CWnd::OnActivate() to maintain it. The call to AfxRegisterWndClass here tells the OS what cursor to associate with this class of window, though of course the cursor will only be valid while the app is running. Doing this provides much cleaner mouse activation.

Gribble1 passed a 0 for the background brush parameter and handled background paints with its own member CBrush. Gribble2 assigns a system brush loaded with GetStockObject to the window class itself. This now means that OnEraseBkgnd doesn't need to explicitly paint the background. The default window procedure will use this brush to fill the background if we don't do it.

Lastly, now an icon is supplied for the window. The gribble window has no title bar, but this icon will display when you hit Alt+Tab to switch between apps - which allows you to differentiate between it and the Gribble2 application.

Setup and Cleanup

One of the quirks of coding windows wrapper classes is that you often deal with two levels of creation and destruction. The class itself can live through many create/destroy cycles of its underlying window, so the initialization and cleanup one would normally associate with the constructor and destructor of a C++ class often gets moved to the OnCreate and OnDestroy message handlers.

Gribble2 follows this pattern:

int CGribbleWnd::OnCreate(LPCREATESTRUCT lpCreateStruct) 
{
    if (CWnd::OnCreate(lpCreateStruct) == -1)
        return -1;

    try {
        // since this window has its own DC 
        // we can stash it away... 
        // Don't just store a CDC pointer returned 
        // by CWnd::GetDC!
        m_zeroTrap = m_ScreenDC.Attach( ::GetDC(m_hWnd));

        Grb2Fn_InitGribble2Stuff();

        // save the taskbar...
        m_ShellTrayHwnd = ::FindWindow(_T("Shell_TrayWnd"), 
            NULL);

        if(m_ShellTrayHwnd != NULL) {
            // ... will we need to set topmost?
            LONG tb_style = GetWindowLong(m_ShellTrayHwnd, 
                GWL_EXSTYLE);
            if(!(tb_style & WS_EX_TOPMOST)) {
                m_ShellTrayHwnd = NULL; // not to worry...
            }
        }

        // Go full screen. SetWindowPos 
        // is more effective 
        // than MoveWindow at obscuring task bar - 
        // but suppress WM_ERASEBKGND 
        SetWindowPos(&wndTopMost, 0,0,m_pixelsX, m_pixelsY,
            SWP_SHOWWINDOW | SWP_DEFERERASE );

        /****************************************************/
        /*WARNING DO _NOT_ STICK A BREAK POINT IN THIS AREA */
        /****************************************************/

        // this creates a memory device context compatible 
        // with our display
        m_zeroTrap = m_QuadrantsDC.CreateCompatibleDC(&m_ScreenDC);

        // this creates a bitmap compatible with our display
        m_zeroTrap = m_QuadrantsBitmap.CreateCompatibleBitmap(
            &m_ScreenDC, m_pixelsX, m_pixelsY);

        // note that we don't bother saving the 
        // old bitmap - while their is
        // a default bitmap associated with a newly created 
        // device context, it is not 
        // really an object that is currently selected 
        // into the DC, and there's 
        // no point in saving it for restoration.
        (void)m_QuadrantsDC.SelectObject(m_QuadrantsBitmap);

        // repeat the above for the Extra DC that will 
        // aid in reflecting image regions
        m_zeroTrap = m_GribbleDC.CreateCompatibleDC(&m_ScreenDC);
        m_zeroTrap = m_GribbleBitmap.CreateCompatibleBitmap(
            &m_ScreenDC, m_pixelsX, m_pixelsY);
        (void)m_GribbleDC.SelectObject(m_GribbleBitmap);
    }
    catch(DWORD) {
        ValidateRect(&m_ScreenRect);
        CString  strMsg;
        m_zeroTrap.GetMessage(strMsg);
        // bad place for a messagebox
        //MessageBox(strMsg, "Error");
        TRACE(_T("Error in OnCreate: %s\n"), strMsg);
        return FALSE;
    }

    // used as clip rgn in QuadrantsDC if desired
    m_QuadCircleRgn.CreateEllipticRgn(m_Q1PointTopLeft.x, 
        m_Q1PointTopLeft.y, 
        m_Q1PointTopLeft.x+m_QuadSize*2,
        m_Q1PointTopLeft.y+m_QuadSize*2);

    // Ok - enough stuff available for OnEraseBkgnd to 
    // do its stuff, so send the WM_SYNCPAINT message
    SendMessage(WM_SYNCPAINT, 0,0 );

    // ok - we've forced our window topmost, without altering the 
    // state of the system tray/taskbar thingy - 
    // but if we leave our window topmost, other windows 
    // will be unshowable on this monitor - so lets
    // get rid of the topmost-ness. Its work here is done...
    SetWindowPos(&wndNoTopMost, 0,0, m_pixelsX, 
        m_pixelsY, /* SWP_SHOWWINDOW |*/ SWP_DEFERERASE );

    /*****************************************************/
    /******** END WARNING ( NO BREAK POINTS ) ************/
    /*****************************************************/

    Grb2Fn_DrawSomethingToGribbleDC();

    return 0;
}

First, OnCreate sets up a CDC member object with a handle to the windows device context - this is unusual for a Windows program. Most windows do not have their own device context. When they need to draw to the screen, they call GetDC and are given a DC from the system cache. They then should call ReleaseDC so that the DC goes back into the cache for other programs to use. In our case, we registered the window class with the CS_OWNDC style. This means that the device context is not taken from the system cache, and is permanently available for our use. Even if it wasn't stored it in our own CDC class, accessing the DC through GetDC would be more efficient, as the system would be able to supply the owned DC more quickly than if it had to go to the cache, but attaching it to a member CDC object makes the setup of the second and third device contexts simpler.

Next, Grb2Fn_InitGribble2Stuff is called to set up some screen metrics and initialize the variables that control the patterns that will be drawn.

You'll see a call to FindWindow that's used to get a handle to the system tray window, aka Windows 95 task bar. This is the beginning of a whole bunch of jumping through hoops to try to make sure that the gribble window is truly full screen at least long enough for the initial screen capture to the background DCs to be free of the taskbar. Gribble1 didn't go to such lengths, and while it usually worked in clearing the whole screen, there were times when it didn't - leaving the taskbar on screen while important gribbling was being performed. Gribble2 needs to be more careful, because the first time OnEraseBkgnd is called, whatever is on the screen will be blitted to the background DCs.

Instead of a simple call to MoveWindow, Gribble2 uses SetWindowPos. The call to SetWindowPos uses the &wndTopMost value, and in doing so makes the window the very topmost window in the system. The call to SetWindowPos can cause the WM_SYNCPAINT (and hence WM_ERASEBKGND) messages to be sent. The SWP_DEFERERASE flag is used here so that doesn't happen - the secondary device contexts and bitmaps need to be set up before OnEraseBkgnd can operate properly.

Armed with the screen metrics set in Grb2Fn_InitGribble2Stuff, OnCreate then sets up the second and third device contexts. These will be used to do the 'background' drawing. The calls to CreateCompatibleDC set up device contexts of the same type as our screens device context (now held in m_ScreenDC). The new device contexts don't duplicate any GDI objects that may be selected into the source DC, but do provide defaults. However, the default bitmap is not what we want for the upcoming BitBlt/StretchBlt exitement, so the code creates bitmaps compatible with our screens device context then selects those bitmap into the newly created 'compatible' DCs. As innocent as this looks, we've now set things up so that images existing on one DC can be rapidly blitted to the other, laying the groundwork for some very smooth graphic display updates.

Next, one circular region is created. This will be selected as the clipping region to the quadrants DC later if the user wants to view the output that way.

Finally, the call to SendMessage(WM_SYNCPAINT,0,0) will trigger the first WM_ERASEBKGND (after a WM_NCPAINT) and OnEraseBkgnd will do its stuff. This is where the initial blits of the erased screen will take place. The windows documentation is a tad vague on what exactly a WM_SYNCPAINT message is for.  I think of it as a 'hey Windows, do your thing like we just got rolled over by some other window' - i.e. a convenient way to get a proper stream of painting messages for a window, rather than trying to fake it by sending or posting paint messages or calling handlers directly. The documentation states that this message is for Win98 and above, but this OnCreate seems to work ok in Win95 as well.

As a side note, its interesting to see what the OS sends to a window when its invalidated by another window:

Windows 98 sends the following to the gribble window when another window moves over it, or at least why my Win98 Spy utility shows as being sent:

<00001> 00000F98 S WM_NCPAINT hrgn:000009E4
<00002> 00000F98 R WM_NCPAINT 
<00003> 00000F98 S WM_ERASEBKGND hdc:0000251E
<00004> 00000F98 R WM_ERASEBKGND fErased:True
<00005> 00000F98 P WM_PAINT hdc:00000000

Windows NT shows the following:

<00001> 001802B4 S WM_SYNCPAINT
<00002> 001802B4 S .WM_NCPAINT hrgn:1D0405AC
<00003> 001802B4 R .WM_NCPAINT
<00004> 001802B4 S .WM_ERASEBKGND hdc:62010332
<00005> 001802B4 R .WM_ERASEBKGND fErased:True
<00006> 001802B4 R WM_SYNCPAINT
<00007> 001802B4 P WM_PAINT hdc:00000000

(The lines with 'S' indicate sent messages - the 'R' lines show the return, and the 'P' stands for a posted message - windows normally 'posts' WM_PAINT messages, giving them a lower priority in the input queue.) 

Note that on NT, the paint messages are nested in the WM_SYNCPAINT processing, which would indicate that they come from the windows default procedure, not the OS. So the WM_SYNCPAINT message, on NT at least, has the effect of reducing the inter-thread communication involved with this painting message sequence.

Also, I had thought that WM_ERASEBKGND messages were only sent as a side effect of processing WM_PAINT messages, but it looks as if this is not true - more thoughts on this below.

Now, where was I. Oh yes - another call to SetWindowPos is made to remove the topmost property - this is important! Without this, our window would obscure all the other applications on this monitor. Also, you might want to avoid setting breakpoints in this code between the two calls to SetWindowPos. Especially if you are working with a single monitor machine. Trust me on this one. Gets a bit annoying. If you do want to do some spelunking here, at least make sure your Task Manager is set to be 'Always on Top'. And if you do get stuck here, kill VC, not Gribble - trying to kill the gribble window or the Gribble2.exe will result in a message box to the effect that TM can't kill a process that is being debugged, and this message box won't be visible. Like I say, gets a bit annoying. 

This might seem like a lot of effort to go to just to keep the task bar off the screen - and in fact, it doesn't work 100% of the time - if you launch VC from a non-primary monitor and are using breakpoints in OnCreate, you might end up with the taskbar showing. Which isn't so bad, really. What I'm really trying to avoid is having a bitmap of the taskbar on the screen (annoying).

Finally, I call a function to draw something to the secondary background DC (the gribble DC), and we're done.

Cleanup goes thus wise:

void CGribbleWnd::OnDestroy() 
{

    CWnd::OnDestroy();

    // Cleanup compatibles
    m_QuadrantsDC.DeleteDC();
    m_GribbleDC.DeleteDC();

    m_QuadrantsBitmap.DeleteObject();
    m_GribbleBitmap.DeleteObject();

    m_QuadCircleRgn.DeleteObject();

    // detatch the HDC we got from ::GetDC.
    // Note that since we are using a private DC there is 
    // no need to Release the DC - it does not
    // come from the DC cache, unless we ask for one 
    // from the cache by using GetDCEx with the 
    // DCX_CACHE flag set.
    m_ScreenDC.Detach();

    m_bErased = false;

    // if necessary, restore the topmost property of 
    // the taskbar...
    if(m_ShellTrayHwnd != NULL) {
        TRACE(_T("Setting tray window to top\n"));
        ::SetWindowPos(m_ShellTrayHwnd, HWND_TOPMOST, 
            0,0,0,0, SWP_NOMOVE);
    }
}

Notice that we don't need to select the bitmaps out of their respective DCs - bitmaps are different from most 'selectable' objects in this regard, so our cleanup becomes quite simple. Just delete the DCs, bitmaps, and region we created in OnCreate.

We don't need to delete the main DC, as it is part of the window - we'll just detach it so that the destructor of the CDC object doesn't get confused. Also, and this is important to note if your new to this device context stuff, we don't need to call ReleaseDC. 

You'll read a lot of texts that discuss device contexts that will tell you that you handle WM_PAINT messages by calling BeginPaint (which calls GetDC), doing your painting, and calling EndPaint (which calls ReleaseDC). If you are doing your rendering outside of the context of a WM_PAINT message, you can call GetDC and ReleaseDC. The point made, correctly, is that when GetDC is called in these cases you receive a DC from the system cache, and it is a resource to be repected and replaced when you are done. Not releasing a DC taken from the system cache is a serious no-no, and can cause resource depletion system wide. However, this gribble window has its own device context associated with it. It doesn't come from the system cache. In fact, you should see very little impact on the GDI resources bar in the Win98 Resource Meter utility while running Gribble2.exe. But you don't want to add this OWN_DC style to all your windows and controls. A device context is a conglomerate of a whole pile of stuff, some of which (e.g. fonts) can take up a lot of memory. The point I'm trying to make here is that the gribble window is departing from convention, but that this is intended to be a special full screen window, and I hope I'm describing the rules well enough that you can see why I'm breaking them.

Finally, if the taskbar was 'always on top' when we created the window, our first call to SetWindowPos would have robbed it of its topmost status - so we'll be nice and restore that. If we don't, after Gribble2.exe exits, the taskbar will appear on screen, but the user will be able to obscure it with other windows, which may not be the way the system was when we found it. If m_ShellTrayWnd is NULL, that means the taskbar didn't have the topmost style bit set when we checked in OnCreate, so no wurries.

OnEraseBkgnd

There seem to be differing philosophies about the proper use of the WM_ERASEBKGND and WM_PAINT handlers in windows programming. The only thread offered so far for the Gribble1 applies to this - why would we have two different messages sent to our window for what is essentially the same task? And why write code in both handlers when we could conceivably do all the work in one?

It happens in our gribble windows case that this setup is a very convenient one. But lets take a quick look at what all this 'painting' stuff is on about first in order to understand why.

The windows OS knows about all the windows that have been created. It knows when they are sleeping, it knows when they're awake, it knows if they've been bad or good, etc. More importantly, it will take action if they become invalid. A window can become invalid (or, perhaps more to the point, a region or rectangle of a window can become invalid) when we explicitly make it so by calling InvalidateRect or InvalidateRgn, or when another window invalidates all or part of the window by appearing over it and moving or closing.

In the case where we invalidate the window explicitly we have some degree of control over whether the WM_ERASEBKGND message will be sent to our application, though a Boolean parameter in the InvalidateRect and InvalidateRgn calls. Actually, this parameter is more of a hint - if other regions are slated for background erasure, the WM_ERASEBKGND message will be sent when the BeginPaint message is called. We'll be able to examine the Boolean fErase flag in the PAINTSTRUCT filled in by the call to BeginPaint after it returns.

This is the normal procedure for a windows application processing the WM_PAINT message, as noted above. The call to BeginPaint also returns the device context handle, validates the update region, and hides the caret (if necessary) while painting is being carried out. A call to EndPaint restores the caret, if one was hidden by BeginPaint, and releases the device context.

WM_ERASEBKGND will also be sent to our app by the system in among the message sequence used to tell a window to paint itself when invalidated by another window or through an explicit WM_SYNCPAINT message. To wit, WM_NCPAINT, WM_ERASEBKGND, and WM_PAINT (posted).

As it turns out, this is a Good Thing, as shown in the code below:

BOOL CGribbleWnd::OnEraseBkgnd(CDC* pDC) 
{
    // the first version of this window used its 
    // own brush to erase the background 
    // - this version passes a background 
    // brush to AfxRegisterWndClass in OnGribbleGo, 
    // so we can
    // concentrate on other stuff.

    //TRACE(_T("Inside OnEraseBkgnd...\n"));

    // Lets assure ourselves that the HDC OnEraseBkgnd  
    // is handing us is the same as our private one - 
    // if so we can assume that 
    // the MFC is respecting our privacy in this regard.

    VERIFY(pDC->m_hDC == m_ScreenDC.m_hDC);

    if(!m_bErased) {
        // here, we only actually erase once, 
        // at the start.
        // Since the window does have its own brush, 
        // returning 0 would probably have 
        // the same effect, but we want to do some init.

        int ret = CWnd::OnEraseBkgnd(&m_ScreenDC);

        // blt to the compat... in effect, 
        // clear our working DC as well
        try {
            // wipe both working DCs - allows for testing 
            // of new tricks etc...
            // Win9x users - comment out the call to 
            // m_GribbleDC for an interesting effect!
            m_zeroTrap = m_QuadrantsDC.BitBlt(0, 0, 
                m_pixelsX,m_pixelsY, &m_ScreenDC, 0, 0, 
                SRCCOPY);
            m_zeroTrap = m_GribbleDC.BitBlt(0, 0, 
                m_pixelsX,m_pixelsY, &m_ScreenDC, 0, 0, 
                SRCCOPY);

        }
        catch(DWORD) {
            ValidateRect(&m_ScreenRect);
            CString  strMsg;
            m_zeroTrap.GetMessage(strMsg);
            MessageBox(strMsg, "Error");
            return FALSE;
        }

        // select special clip region, if desired
        if(m_bUseCircle) {
            m_QuadrantsDC.SelectClipRgn(&m_QuadCircleRgn, 
                RGN_COPY);
        }

        m_bErased = true;
        return ret;
    }
    else {
        // only erase the background if another window is 
        // being dragged over us - 
        // better yet, just blit the screen bitmap -
        // and our window just stays the way it is - 
        // very smooth!
        if(GetForegroundWindow() != this) {
            m_ScreenDC.BitBlt(0, 0, m_pixelsX,m_pixelsY, 
                &m_QuadrantsDC, 0, 0, SRCCOPY );
        }
        return true;
    }

}

So, what gives here? Well, the first time we enter this function (indirectly by way of the SendMessage(WM_SYNCPAINT,0,0) call in OnCreate) we erase the background by calling CWnd::OnEraseBknd. Actually, we could just return false and gain the same result (the default window proc will use the class background brush to erase the background), but we want to do one last bit of setup here. After the return from CWnd::OnEraseBknd, we want to copy the newly blotted out screen to our background device contexts. Now we can work with a clean slate as it were.

Note that its also in this 'one time only' processing that the clipping region of the primary background DC (what I call the quadrants DC) is set to the circular region set up in OnCreate, if that Boolean is set.

During the periods in which the gribble window has focus, painting will be triggered by calls to InvalidateRect with a value of FALSE for the bErase parameter, so OnEraseBkgnd shouldn't fire if we call BeginPaint. But, as noted above, the WM_SYNCPAINT type message sequence that occurs when the gribble window is invalidated by another can send us here as well, and I make a call to GetForegroundWindow to determine (almost a given) if we are indeed dealing with forces beyond our control. (Note that not all windows can use such a simple test - it definitely helps to be a full screen window!) All OnEraseBkgnd needs to do in this situation is blit the primary background DC bitmap to the screen DC and we're done! Our window's invalid region is updated with the absolute minimum of flicker and other kafuffle of that nature. This is beautifully smooth. Try it, you'll like it!

OnPaint

And now, ladies and gents, the lovely and talented OnPaint.

void CGribbleWnd::OnPaint() 
{
    //CPaintDC dc(this);      
    // thanks, we already got one...

    // since we are using a private device context, 
    // and not calling BeginPaint
    // (by way of CPaintDC), we are responsible 
    // for validating the affected 
    // area - if we don't do this, the system will 
    // continue to send us WM_PAINT 
    // messages.  Also, this seems to work only 
    // if we validate the whole screen, 
    // even though we called InvalidateRect on a 
    // smaller portion.
    ValidateRect(&m_ScreenRect);

    // if we're not just painting because some nasty 
    // window is dancing the Macarena over us...
    if(GetForegroundWindow() == this) {
        // call whatever nifty paint function you got...
        // the gribble DC is drawn to at start and on 
        // left click 
        Grb2Fn_BlitGribbleToQuadrantsDC();
    }

    // ...then transfer the artwork wholesale 
    // to our screens DC
    try {
        m_zeroTrap = m_ScreenDC.BitBlt(0, 0, 
            m_pixelsX,m_pixelsY, &m_QuadrantsDC, 
            0, 0, SRCCOPY );
    }
    catch(DWORD) {
        ValidateRect(&m_ScreenRect);
        CString  strMsg;
        m_zeroTrap.GetMessage(strMsg);
        MessageBox(strMsg, "Error");
    }

    if(GetFocus()==this) {
        Sleep(m_nSpeed);
        InvalidateRect(&m_KaleideRect, FALSE);
    }


    // Do not call CWnd::OnPaint() 
    // for painting messages
}

Points of note - firstly, we don' need no stinking don't need to call BeginPaint. There's no caret to hide and we have our own DC to play with, thanks. 

We do, however, need to validate our window. Note that you can sort-of-kind-of get away with not calling ValidateRect here, but it means that the OS will continually harass your application with WM_PAINT messages. Not a good thing. Even though WM_PAINT messages are typically posted to the thread and have a low priority, having a surplus of them in the threads input queue will make it difficult for other messages to get through. The call to Sleep helps a bit, since when the thread wakes up the important messages tend to get the respect they deserve, but its still good advice to validate your window post haste inside a WM_PAINT handler.

OnEraseBkgnd will not be called, not because we set bErase to false when we invalidated, but because we're not using BeginPaint. (The CPaintDC object whose creation is commented out would have caused BeginPaint to be called).

Next, we call a method that draws whatever updates we need to the primary background compatible DC (set up in OnCreate and cleared in the initial call to OnEraseBkgnd) and then blit that to the screen DC.

However, its still nice to determine, as we did in OnEraseBknd, whether we're being asked to paint something new (our own InvalidateRect) or in response to some VB based bloated cow of an application slobbering all over our real estate - so I put the call in to GetForegroundWindow here as well. Actually making the call to BitBlt in this situation may be overkill. If a WM_PAINT message arrives when the gribble window doesn't have focus, chances are that OnEraseBkgnd has done the blit work. Note that calling ValidateRect inside OnEraseBkgnd in this situation will not suppress the WM_PAINT message posted at the end of the WM_SYNCPAINT type message flow.

Lastly, if we have focus, a call to Sleep allows the user to slow things down (to a max of 1 second, given the property dialogs restrictions) and we call InvalidateRect to start again. You might want to change this to use a timer, which is the normal way of things for screen savers and the like. Using sleep makes the app less responsive, but invalidating here is convenient - if we validate the rect when we lose focus, or in response to a right click, or an exception handler, we stop the process without further ado. 

Gribble me this, Blitman!

So, what's all this blitting stuff going to accomplish? Nice of you to ask. Bloody amazing you're still reading at this point, actually Well, originally my idea was to make a kaleidoscope. Really. But making a realistic kaleidoscope requires intelligence the ability to rotate images in non-trivial ways, and all the good rotation transforms are only available on NT, not Windows 9x, so I settled for... um... well, whatever. Call it a Gribeidoscope I guess...

All the interesting stuff here takes place in two CGribbleWnd member functions, Grb2Fn_DrawSomethingToGribbleDC and Grb2Fn_BlitGribbleToQuadrantsDC. 

Grb2Fn_DrawSomethingToGribbleDC draws, as the name suggests, a something to the gribble DC. This is background DC behind the real background DC, which I call the quadrants DC. Grb2Fn_DrawSomethingToGribbleDC splits the gribble square into two triangles, and reflects each item drawn by swapping x and y coordinates and alternately setting each triangle as the clip region for the gribble DC. This allows reflection on the diagonal dissecting the square, which is unavailable with the simple flips on the x and y axis available with the StretchBlt function.

Then, in OnPaint, Grb2Fn_BlitGribbleToQuadrantsDC is called and, starting at the top left corner, and performs three StretchBlt calls that copy a quarter of the gribble square to the top left of the quadrants square (DC), then reflect that square into the bottom left quadrant, then reflect that half to the right half, and we have our gribeidosopic effect. 

Grb2Fn_DrawSomethingToGribbleDC is called when the gribble window is first created, and when the user left clicks in the window. (You'll have to left click a few times before the gribble gets interesting.)

/* ***********************************************

For a Kaleidescopic effect, we would really want 
to flip a portion of an existing image 
(1) along its diagonal, to generate the first 
reflection. All we can do with the Win9x
API is flip on the X or Y axis - simulating a flip 
on the hypotenuse would require one h flip
and a rotation. With Win NT/2000 rotations are 
available - but not Win9x. So, we'll fake 
it by trying to do the 'flip' in the rendering 
to the gribble DC - essentially, draw everthing
twice...

- - - - - - - - - - - - - -  
| \                       |
|   \                     |        
|     \        rgn2       |         
|       \                 |      
|         \               |      
|           \             |      
|             \           |      
|               \         |      
|     rgn1        \       |      
|                   \     |      
|                     \   |      
|                       \ |      
- - - - - - - - - - - - - - 

*********************************************/

BOOL CGribbleWnd::Grb2Fn_DrawSomethingToGribbleDC()
{
    BOOL retval = TRUE;
    CRgn rgn1, rgn2;        // for clipping

    POINT   pPoints1[3] = {m_KaleideRect.left, 
        m_KaleideRect.top, 
        m_KaleideRect.left, m_KaleideRect.bottom,
        m_KaleideRect.right, m_KaleideRect.bottom };
    POINT   pPoints2[3] = {m_KaleideRect.left, 
        m_KaleideRect.top, 
        m_KaleideRect.right, m_KaleideRect.top,
        m_KaleideRect.right, m_KaleideRect.bottom };

    rgn1.CreatePolygonRgn(pPoints1, 3, ALTERNATE);
    rgn2.CreatePolygonRgn(pPoints2, 3, ALTERNATE);


    // get ready to draw, podner...
    srand( (unsigned)time( NULL ) );
    COLORREF  clr = RGB(rand()%256, rand()%256, rand()%256);

    static POINT pts[4096];
    for (int i = 0; i < 4096; i++) {
        pts[i].x = rand()%(m_QuadSize*2);   
        pts[i].y = rand()%(m_QuadSize*2);
    }

    // lines, triangles and dots - oh my!
    switch(m_gribbleType) {
    case dots: 
        m_GribbleDC.SelectClipRgn(&rgn1, RGN_COPY);
        for (i = 0; i < m_nDots; i++ ) {
            m_GribbleDC.SetPixel ( m_KaleideRect.left + pts[i].x, 
                m_KaleideRect.top + pts[i].y, clr);
        }
        m_GribbleDC.SelectObject(&rgn2);
        for (i = 0; i < m_nDots; i++ ) {
            m_GribbleDC.SetPixel ( m_KaleideRect.left + pts[i].y, 
                m_KaleideRect.top + pts[i].x, clr);
        }
        break;
    case lines: {
        CPen pen(PS_SOLID, 0, clr);
        CPen *pOldpen = m_GribbleDC.SelectObject(&pen);
        POINT p[2];

        m_GribbleDC.SelectClipRgn(&rgn1, RGN_COPY);
        for (i = 0; i < m_nLines*2; i+=2 ) {
            p[0].x = m_KaleideRect.left + pts[i].x;
            p[0].y = m_KaleideRect.top + pts[i].y;
            p[1].x = m_KaleideRect.left + pts[i+1].x;
            p[1].y = m_KaleideRect.top + pts[i+1].y;
            m_GribbleDC.Polyline(p,2);
            // the LineTo call was easier on the eyes, 
            // but resulted in some unwanted 
            // horizontal lines in the output...
            // m_GribbleDC.LineTo(m_KaleideRect.left + 
            // pts[i].x,m_KaleideRect.top + pts[i].y);
        }

        m_GribbleDC.SelectClipRgn(&rgn2, RGN_COPY);
        for (i = 0; i < m_nLines*2; i+=2 ) {
            // there is an xy swap going on here 
            p[0].x = m_KaleideRect.left + pts[i].y;
            p[0].y = m_KaleideRect.top + pts[i].x;
            p[1].x = m_KaleideRect.left + pts[i+1].y;
            p[1].y = m_KaleideRect.top + pts[i+1].x;
            m_GribbleDC.Polyline(p,2);
        }
        m_GribbleDC.SelectObject(pOldpen);
                }
                break;
    case triangles: {
        // much like lines, but with 3 points to worry about...
        CPen    pen(PS_SOLID, 0, clr);
        CBrush  brsh(clr);
        CPen *pOldpen = m_GribbleDC.SelectObject(&pen);
        CBrush *pOldbrsh = m_GribbleDC.SelectObject(&brsh);
        POINT p[3];

        m_GribbleDC.SelectClipRgn(&rgn1, RGN_COPY);
        for (i = 0; i < m_nTriangles*3; i+=3 ) {
            p[0].x = m_KaleideRect.left + pts[i].x;
            p[0].y = m_KaleideRect.top + pts[i].y;
            p[1].x = m_KaleideRect.left + pts[i+1].x;
            p[1].y = m_KaleideRect.top + pts[i+1].y;
            p[2].x = m_KaleideRect.left + pts[i+2].x;
            p[2].y = m_KaleideRect.top + pts[i+2].y;

            if(m_bConstrain) {
                Grb2Hlp_ForcePointInRgn(&rgn1, p[0]);
                Grb2Hlp_ForcePointInRgn(&rgn1, p[1]);
                Grb2Hlp_ForcePointInRgn(&rgn1, p[2]);
            }

            m_GribbleDC.Polygon(p,3);
        }

        m_GribbleDC.SelectClipRgn(&rgn2, RGN_COPY);
        for (i = 0; i < m_nTriangles*3; i+=3 ) {
            // there is an xy swap going on here 
            p[0].x = m_KaleideRect.left + pts[i].y;
            p[0].y = m_KaleideRect.top + pts[i].x;
            p[1].x = m_KaleideRect.left + pts[i+1].y;
            p[1].y = m_KaleideRect.top + pts[i+1].x;
            p[2].x = m_KaleideRect.left + pts[i+2].y;
            p[2].y = m_KaleideRect.top + pts[i+2].x;

            if(m_bConstrain) {
                Grb2Hlp_ForcePointInRgn(&rgn2, p[0]);
                Grb2Hlp_ForcePointInRgn(&rgn2, p[1]);
                Grb2Hlp_ForcePointInRgn(&rgn2, p[2]);
            }

            m_GribbleDC.Polygon(p,3);
        }
        m_GribbleDC.SelectObject(pOldpen);
        m_GribbleDC.SelectObject(pOldbrsh);
                    }
                    break;

    default:
        break;
    }

    // note that SelectClipRgn with RGN_COPY := SelectObject, 
    // but for nMode param - 
    // we could use SelectObject(&rgn1) here with the 
    // same result.

    return retval;

}

The Grb2Hlp_ForcePointInRgn function is used to fit triangles into a region. You can try this effect by selecting the Constrain checkbox in the properties dialog.

// expects a region which is a half square split 
// on the diagonal.
// any point in the square that is not in the region in
// question can be mapped into it by swapping x and y.
// DrawSomethingToGribbleDC uses this to stop the spread of
// mutant blobby triangles
void CGribbleWnd::Grb2Hlp_ForcePointInRgn(CRgn *rgn, POINT& p)
{
    if(!rgn->PtInRegion(p)) {
        // swap x and y
        register int x,y;
        x = p.x - m_Q1PointTopLeft.x;   // strip offset
        y = p.y - m_Q1PointTopLeft.y;
        p.x = m_Q1PointTopLeft.x + y;
        p.y = m_Q1PointTopLeft.y + x;
    }
}

Grb2Fn_BlitGribbleToQuadrantsDC copies ever changing portions of the gribble square to the quadrants DC to give the effect of movement. This is called in OnPaint when we have focus.

/* **************************************************

Imagine a square divided into four quadrants: 

     - - - - - - - - - - - - - - 
Q1   |            |            |  
     |            |            | 
     |            |            | 
     |            |            | 
     |            |            | 
H1 { | - - - - - - - - - - - - | } H2
     |            |            | 
     |            |            | 
     |            |            | 
Q4   |            |            |  
     |            |            | 
     |            |            | 
     - - - - - - - - - - - - - - 

1. StretchBlt some area of the Gribble DC into Q1.
2. Flip Q1 into Q4 with a 1 to 1 StretchBlt, mirroring y axis.
3. Flip H1 into H2 with a 1 to 1 StretchBlt, mirroring x axis.

// *************************************************** */
BOOL CGribbleWnd::Grb2Fn_BlitGribbleToQuadrantsDC()
{
    BOOL retval = TRUE;
    try {
        // blit stuff to Q1 - we can affect the 
        // whole reflection here
        m_zeroTrap = m_QuadrantsDC.StretchBlt(
            m_Q1PointTopLeft.x, m_Q1PointTopLeft.y, 
            m_QuadSize, m_QuadSize,
            &m_GribbleDC, 
            m_Q1PointTopLeft.x + m_nBlitPos, 
            m_Q1PointTopLeft.y + m_nBlitPos, 
            m_QuadSize/m_nStretchX, m_QuadSize/m_nStretchY, 
            SRCCOPY );    

        // stretch blit Q1 into Q4...
        m_zeroTrap = m_QuadrantsDC.StretchBlt(
            m_Q1PointBottomLeft.x, m_Q1PointBottomLeft.y, 
            m_QuadSize, m_QuadSize, 
            &m_QuadrantsDC, 
            m_Q1PointBottomLeft.x, m_Q1PointBottomLeft.y-1, 
            m_QuadSize, -m_QuadSize,  // mirror Y
            SRCCOPY );

        // then flip H1 to H2.
        m_zeroTrap = m_QuadrantsDC.StretchBlt(
            m_Q1PointTopRight.x, m_Q1PointTopRight.y,
            m_QuadSize, m_QuadSize*2,
            &m_QuadrantsDC, 
            m_Q1PointTopRight.x-1, m_Q1PointTopRight.y,
            -m_QuadSize, m_QuadSize*2,     // mirror X
            SRCCOPY );

        // if we've travelled halfway down the diagonal, 
        // or gone back to the top, reverse direction. 
        m_nBlitPos += m_nDirection;
        if(m_nBlitPos == m_QuadSize) {
            m_nDirection = -1;
        }
        else {
            if(m_nBlitPos == 0) {
                m_nDirection = 1;
            }
        }

    }
    catch(DWORD) {
        ValidateRect(&m_ScreenRect);
        CString  strMsg;
        m_zeroTrap.GetMessage(strMsg);
        MessageBox(strMsg, "Error");
        retval = FALSE;
    }


    return retval;
}

Misc

There is a properties dialog implemented to allow the user to select the type of gribble to be used (dots, lines, or triangles) and various other settings. Current settings are stored in the registry under HKCU\Software\Gribble\Gribble2.

Error handling

I noticed that most GDI calls returned 0 for failure, and that some (but not all) required a call to GetLastError to determine the cause of the failure. I got tired of doing error checks on every call, so I created a small class called CZeroResultTrap whose sole purpose in life is to grab the last error and throw an exception if it is assigned a 0. If the GetLastError call returns 0, it will report a generic message. I leave it in to make the error checking less intrusive, but don't recommend you rush out and use it in any production apps. Its also interesting to note that some GDI calls simply don't fail - selecting a default (stock) object into a screen DC with MM_TEXT mapping mode, for example, or palette selection, which has no memory requirements. If you'd like to see where I stole that info See the article "GDI OBJECTS" in the MSDN for more on this.

Summary

The performance of this gribble graphic is not going to win any awards, and the math (if you can call it that) is pretty simple. I'm hoping the article is useful for its discussion of the windows paint messages and how they can be handled, and perhaps some simple blitting ideas. I don't think I've exhausted all the issues here, so check for flames feedback on this article before betting your salary on these techniques. 

Happy Gribbling