I have to ask, is there a reason each thread uses its own display connection
(which are all different from gdi_display), and leaves the window data to
only be available from the thread the window was created in? Besides the
aforementioned problem with the GL context, I'd imagine it would be
done!
With luck, they can be gotten to a point soon where they can be rewritten
properly to get into Wine.
Hope so because it's very important to get this in main tree before 1.0
release. Now with your patchs all 3D professional software (which unusable
because of OpenGL child windows
On 10.01.2007 07:27, Chris Robinson wrote:
Beyond that, the only problem I can recall off-hand is that the OpenGL window
will draw overtop of all Win32 windows that are sharing the same X11 parent
window.
Hmm, if OGL is displayed in its own child window, maybe it's possible to
shape it so
On Wednesday 10 January 2007 12:22, Frank Richter wrote:
Hmm, if OGL is displayed in its own child window, maybe it's possible to
shape it so that overlapping Win32 child windows are excluded...
I'm not sure how to do that, given that the overlaps can cause the child
window to have concave
be removed (they aren't removed here,
instead just piped directly to the appropriate gl* function with no
alteration, since that would require changes to opengl32). OpenGL in Win32
child windows is improved by being restrained to the Win32 windows' extents,
as seen in the screen-grab here in VLC
On 12/31/06, Chris Robinson [EMAIL PROTECTED] wrote:
The topic of getting OpenGL to show and use more visuals/pixel formats than
just the one the main window uses came up on IRC, and I was told to make a
post here. One of the ideas was to create a child window of the main X window
(which can be
windows, and has fixed numerous painting and z-order related
problems. If you or somebody else are really interested to go backwards,
show us the code which cleanly passes 'make test' in dlls/user32 and
simultaneously solves the problem for OpenGL child windows.
--
Dmitry.
do), but rather, a child window of the main window used solely for
showing OpenGL on. I can't, in my admittedly limited knowledge, think of why
it wouldn't work, and it should also help clear the problem Wine has with
Win32 child windows using OpenGL since they'd implicitly clip to the child
with OpenGL child windows
works (GoogleEarth for Linux for example which has same interface as in its
Windows version). At least I do not know any good solution of this problem
without creating X11 subwindow.
doesn't do), but rather, a child window of the main window used solely for
showing OpenGL on. I can't, in my admittedly limited knowledge, think of
why
it wouldn't work, and it should also help clear the problem Wine has with
Win32 child windows using OpenGL since they'd implicitly clip
windows for child
Win32 windows, and has fixed numerous painting and z-order related
problems. If you or somebody else are really interested to go backwards,
show us the code which cleanly passes 'make test' in dlls/user32 and
simultaneously solves the problem for OpenGL child windows.
I'm
has with
Win32 child windows using OpenGL since they'd implicitly clip to the child
window extents, instead of trying to hack the scissors test. The X11 child
window for OpenGL would be completely transparent to the app (as in,
opengl
wouldn't announce its existance, and the rest of the code
Wine has
with
Win32 child windows using OpenGL since they'd implicitly clip to the
child
window extents, instead of trying to hack the scissors test. The X11
child
window for OpenGL would be completely transparent to the app (as in,
opengl
wouldn't announce its existance, and the rest
On Sunday 31 December 2006 11:44, Mark Hatsell wrote:
Just wondered what would happen in the case of a non-X11 child window
partially overlapping an X11 OpenGL window? I guess this wouldn't work
still even with this solution. This could happen quite easily in an MDI
situation.
I suppose the
The topic of getting OpenGL to show and use more visuals/pixel formats than
just the one the main window uses came up on IRC, and I was told to make a
post here. One of the ideas was to create a child window of the main X window
(which can be given a different visual) and have OpenGL use that
Am Montag 24 Juli 2006 22:01 schrieb Florian Köberle:
When OpenGL draws, child windows get overdrawn.
The suggestions to solve these problem where all based on the idear of
clipping that what OpenGL render so that OpenGL doesn't overdraw them.
What do you think of the idear of letting OpenGL
16 matches
Mail list logo
