[vtkusers] Bug in vtkDataArray.cxx; was: Bug in vtkWin32OpenGLRenderWindow when using own Interactor and windowhandle

[Roland Schwarz]

Sander,


> This MFCHandledWindow parameter makes things indeed more complicated.
> But regretfully your suggestion would not work. If MFCHandledWindow
> would be true, than the ren->SetRenderWindow(NULL) in the clean routine
> still wouldn't be called, which was my initial concern.
>

Hmmm,
this is what I had in mind. But I am not really sure what the
MFCHandledWindow is meant for.

As far as I understand, once you have set the DC of the RenderWindow
manually, you signal that you take responibility for all the things like
creating a opengl context and the like. (WindowInitialize resp. Initialize
will not do this for you any more in this case.)

Therefore it seems logically to me that the RenderWindow should keep hands
off this resources when destroying the window.

If you have simply set the Parent and Wind id's the MFCHandledWindow flag
stays false, so there should not be any problems.

> One thing I was also wondering about is the release of the device
> context. I guess this shouldn't be released if MFCHandledWindow is set
> to true, but what should happen if OwnWindow is false?
>

When the RenderWindow does not 'own' the windows window it should not
release the DC, because it did not 'create' it.
But wait: 'owning' a device context is a somewhat problematic term in
windows programming anyway.
Normally a window never owns a DC. DC's are a shared resource and have been
very limited in number in Windows 98 times and before.
OpenGL windows however often are created using a class with CS_OWNDC
attribute. And so does the vtkWin32OpenGLRenderWindow when it owns the
window. Things are very different when you embed the window. Even if you are
setting the WindowId to do so, you are still responsible that you use a
class with its own DC.

But wait again: OpenGL on windows does not any more need a class with its
own DC. DC's are required to have the same Pixelformat however.

So what do I want to say?

A better name for MFCHandledWindow would be: DontOwnDC or the like.

Or to say it positively :-) : OwnDC (and revert the logic of course)

> Anyway, I think that it would be wise that the person who is going to do
> the bugfixing tries to get things straight in the
> vtkWin32OpenGLRenderWindow class when it comes to initialization and
> cleanup of Win32 windows, DCs, VTK object references, etc. and not just
> focusses on the two problems we are having. I'm not sure, but our
> problems suggest that there might be more broken with regard to proper
> initialization/cleanup than we currently now.

I agree. But I don't think there is broken that much. I think the
vtkWin32OpenGLRenderWindow is a VERY clever implementation. It's usage
however is not so obvious. I am not sure if anyone not with deep knowledge
of window programming will be able to correctly use it. You can see this
i.e. in the Win32SampleMFC where the

  cs.style |= WS_CLIPSIBLINGS | WS_CLIPCHILDREN | CS_OWNDC;
  return CView::PreCreateWindow(cs);

claims to get a window with it's own DC. In fact this code DOES NOT create
such a window, the flag simply is misused in this case but fortunately does
not much harm anyway.

The only really bad thing I can see is that the Render function is not
overridden. In windows you do not usually directly draw to a device context
except in a resonse to the WM_PAINT message. Altough you can do so, you are
defeating the optimization of the drawing that windows does on its own.
(i.e. windows does not send WM_PAINT to invisible or minimized windows.) The
overridden Render function simply should issue a call to Invalidate() and
delegate the actual invocation to render to the WM_PAINT handler.

Sorry for my mail beeing somewhat lenghty,

Roland