Hi Melchior,
FWIW, a fix has already been submitted to get rid of this behaviour on the
Win32 platform. The submission is still pending due to corresponding changes
being required on the Linux OSX platforms. If you're willing to submit
your fix, we'd be one step closer to having this fixed for
Hi J-W,
I'm assuming you are running on the Windows platform right ?
If so, this is the expected behaviour and is a consequence of the way
Windows processes move resize events. When a move event is processed,
Windows will not return control to the message loop until the mouse button
has been
Hi Jean-Sébastien,
Looks like the constructor of the base class (GraphicsWindowWin32) is not
being called by your derived class (_realized is false).
André
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jean-Sébastien Guay
Sent: February-15-08 3:39 PM
Hi Jean-Sébastien,
This looks fine. Try setting a breakpoint in
GraphicsWindowWin32::swapBuffersImplementation() to see in what state the
object is. Either _realized is false or the handle to the device context is
invalid (and this is not trapped by the ::SwapBuffers call as an error). I
assume
Hi Jean-Sébastien,
I'll try that on Monday. I already traced through the
GraphicsWindowWin32::createWindow() method and all looked fine (after
getting the window classes registered as I mentioned before).
BTW, I don't know if you've seen the thread, but could you bring your
insight (as
Hi Leif Robert,
This is the same problem that was reported this summer on the Win32
platform. A fix for it was prepared and submitted, but it required
equivalent changes on the X11 and OSX graphics windows class implementations
since changes to the core OSG libraries were made. It would be great
Hi Jason,
When a graphics window (Win32) is created, it is set by default to be at the
top of the windows Z-order. This is done at line 1629 of
GraphicsWindowWin32.cpp, i.e.
if (!::SetWindowPos(_hwnd, HWND_TOP, _windowOriginXToRealize,...))
You might want to check using other values
Hi Paul,
1. I always understood reentrant to refer to code or an object that
could
be executed safely by multiple threads or processes. However, the
ReentrantMutex would only be used for code that is safe for the _same_
thread or process to execute concurrently, thus my confusion. Is the name
Hi Paul,
The difference is that ReentrantMutex will not block if the caller is
already holding the mutex and is trying to lock() it again (there is a lock
count maintained); you can therefore nest calls to routines using this type
of mutex without fear of self-deadlocking the caller. With
9 matches
Mail list logo
