C++/VB - Intellipoint (iPoint) driver seems to break GDI+ drawing

Asked By noma

20-May-08 04:28 AM

[Inadvertantly originally posted to
microsoft.public.win32.programmer.directx.graphics]

While trying to debug the cause of some customer complaints involving
overpainted windows and image flickering, I wrote a simple MFC test app that
opens a document window (derived from CFrameWnd), which contains a single
view (derived from CView). It also creates a single floating tool window
(derived from CDialog, with the WS_EX_TOOLWINDOW style set).

If one launches the app, places the tool window over the document window,
then begins resizing the document window or moving the main frame window
around underneath the tool window, eventually the contents of the tool window
are filled with the contents of the document window. In addition, the
contents of the document window will be shifted and split, as though the
clipping region or the drawing coordinates had been incorrectly shifted.

Using msconfig, I eventually found that the Intellipoint mouse driver,
ipoint.exe, seems to be the cause of this problem. If the driver is disabled,
or if version 5.5 or earlier of the driver is installed, the problem goes
away.

The drawing code in my test app is in the local view class's implementation
of OnDraw(), and looks like this:

void CIntellipointView::OnDraw(CDC* pDC)
{
CIntellipointDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
if (!pDoc)
return;

/*
Draw some simple shapes.
*/
CRect clientRect;
this->GetClientRect(&clientRect);

Graphics g(*pDC);
int r;
int i;

for (i = 0; 100 > i; ++i)
{
Rect frame;

r = (rand() * 100) / RAND_MAX;

frame.X = (rand() * clientRect.Width()) / RAND_MAX;
frame.Y = (rand() * clientRect.Height()) / RAND_MAX;
frame.Height = r;
frame.Width = r;

Color col((rand() * 255) / RAND_MAX, (rand() * 255) / RAND_MAX,
(rand() * 255) / RAND_MAX);

SolidBrush b(col);

g.FillEllipse(&b, frame);
}
}

If I replace this code with with GDI code (creating CBrush and CPen objects
and selecting them into *pDC, and then using CDC::Ellipse() instead of
Graphics::FillEllipse()), the problem also vanishes. So, apparently, there's
some kind of strange interaction going on between the ipoint.exe driver and
the Graphics object wrapping the HDC.

The problem is 100% reproducible, on any XP or Vista system. I don't think
I'm doing anything strange here, but if somebody thinks otherwise, let me
know. Otherwise, I think this could well be the problem that a lot of people
have been complaining about involving the ipoint.exe driver.

Does anyone see that I'm doing anything wrong?

19-Jun-08 06:56 PM

I just now came to this newsgroup to find information about this same
bug.  I haven't been following the discussions about it, so anything I
say might have already been said.

The two main symptoms I see are painting at inappropriate times and using
wrong coordinates.  Both symptoms don't always happen together.  I don't
know whether it only happens with GDI+.  One way to demonstrate the
inappropriate paint symptom is to play Freecell.  Around five seconds
after an appropriate repaint of the Freecell window, it does the
inappropriate paint, and you can see the Freecell window flicker.  But
the coordinate bug doesn't show there.  In Freecell, as everywhere, it
only happens when ipoint.exe is running.

I'm using Lispworks and accessing GDI+ via the Lispworks foreign function
interface.  So it has nothing to do with the programming language you're
using or anything related to it.  I'm using the flat GDI+ API.

When wrong coordinates are used, the clipping region is still correct.
Also, I only see the wrong coordinate symptom when drawing text, but that
may be just because that's what I happen to be looking at then.

It actually does two inappropriate paints, one right after the other.
Both of them are roughly five seconds after the appropriate paint.  The
wrong coordinates are different in the two inappropriate paints.

This is probably two bugs working together.  One in ipoint.exe and one in
GDI+.