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 g
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 re
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
T
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 yo
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
>> in
Hi Robert,
FYI you might want to check the Boost::intrusive_ptr implementation (similar
in concept to OSG's ref_ptr) as it is using an underlying implementation
that does atomic reference counting (using CPU native Interlocked
test/increments). Note that I'm not suggesting to use Boost, just to ge
Hi Gert,
FYI, I've just submitted a fix for the taskbar not being repainted when a
full-screen graphics window is going to windowed mode.
André
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gert van
Maren
Sent: September-16-07 3:30 AM
To: osg-users@lis
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 Anders,
FYI, Ive submitted a fix for this issue. Once merged by Robert, let me know
if you still have issues doing these operations.
André
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anders
Backman
Sent: September-20-07 2:55 AM
To: osg-users@lists.openscenegraph.o
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 for
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
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 Mutex
12 matches
Mail list logo
