On Tue, Mar 29, 2011 at 5:58 PM, Matteo Bruni wrote:
> 2011/3/29 Roderick Colenbrander :
>> The fact that a pixel format is not set on the physDev doesn't
>> necessarily mean it is invalid, it just means SetPixelFormat wasn't
>> called on it. Though slightly earli
2011/3/29 Roderick Colenbrander :
> The fact that a pixel format is not set on the physDev doesn't
> necessarily mean it is invalid, it just means SetPixelFormat wasn't
> called on it. Though slightly earlier in wglMakeCurrent we already
> catch that situation when compare t
The fact that a pixel format is not set on the physDev doesn't
necessarily mean it is invalid, it just means SetPixelFormat wasn't
called on it. Though slightly earlier in wglMakeCurrent we already
catch that situation when compare the pixel format of the context and
the hdc.
Is
On Sa, 2009-09-19 at 13:15 +0200, Rico Schüller wrote:
> > +ret = wglMakeCurrent( NULL, NULL );
> > + ok( !ret, "wglMakeCurrent failed\n" );
> >
> > shouldn't that message read "wglMakeCurrent succeeded" ?
> Yes, probably something lik
2009/9/19 Rico Schüller :
> Yes, probably something like "wglMakeCurrent succeeded, but should fail!" is
> really a better solution.
>
For what it's worth, I think the exclamation mark might be a bit
overly dramatic. It's not like e.g. your printer is on fire. :-)
Am 19.09.2009 12:29, schrieb Rico Schüller:
Hi,
this patch series fixes a bug which happens on windows with wined3d.
There a second call to wglMakeCurrent(NULL, NULL) fails, which will in
one case result in an early return in context_set_current(), which
doesn't set the the current co
(-)
+ ret = wglMakeCurrent( NULL, NULL );
+ ok( !ret, "wglMakeCurrent failed\n" );
shouldn't that message read "wglMakeCurrent succeeded" ?
Yes, probably something like "wglMakeCurrent succeeded, but should
fail!" is really a better solution.
If
Am 19.09.2009 12:46, schrieb Paul Vriens:
On 09/19/2009 12:29 PM, Rico Schüller wrote:
---
dlls/opengl32/tests/opengl.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
+ret = wglMakeCurrent
On 09/19/2009 12:29 PM, Rico Schüller wrote:
---
dlls/opengl32/tests/opengl.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
+ret = wglMakeCurrent( NULL, NULL );
+ok( !ret, "wglMakeCu
Chris Robinson a écrit :
> On Saturday 21 February 2009 2:00:26 pm Jérôme Gardou wrote:
>
>> according to
>> http://msdn.microsoft.com/en-us/library/dd374387(VS.85).aspx,
>> wglMakeCurrent proceeds a flush before switching.
>>
> glXMakeCurrent also forces
On Saturday 21 February 2009 2:00:26 pm Jérôme Gardou wrote:
> according to
> http://msdn.microsoft.com/en-us/library/dd374387(VS.85).aspx,
> wglMakeCurrent proceeds a flush before switching.
glXMakeCurrent also forces a flush:
http://www.opengl.org/documentation/specs/man_pages/hardcop
wrapper that calls the corresponding driver entry point. For
> > functions that don't need to access the DC, opengl could call x11drv
> > directly, though of course if everything goes through GDI it will make
> > it easier to support opengl with a different driver.
>
> Ba
ed to access the DC, opengl could call x11drv
> directly, though of course if everything goes through GDI it will make
> it easier to support opengl with a different driver.
>
Based on your ideas, I did the following:
- added a new gdi driver function: 'wglMakeCurrent'
- move wglM
Tomas Carnecky <[EMAIL PROTECTED]> writes:
> Even is the functions were implemented in x11drv.. wglMakeCurrent()
> still takes a HDC as an argument so the issue how to change the
> X11DRV_DEVICE given a HDC would remain. The escape mechanism seems to be
> the only way to commun
Alexandre Julliard wrote:
> What we probably want is to move a lot more of the glX code into
> x11drv, and export the various wgl functions from there. That escape
> mechanism is beginning to be seriously abused.
>
Even is the functions were implemented in x11drv.. wglMakeCurrent()
s
Tomas Carnecky <[EMAIL PROTECTED]> writes:
> Why do I have the impression that when it comes to x11drv/opengl nobody
> wants to take the responsibility. I won't submit a patch until someone
> says 'tom, your approach looks good, improve this and then submit a
> patch to wine-patches' or 'tom, no,
Message d'origine
>Date: Tue, 09 May 2006 18:00:52 +0200
>De: Tomas Carnecky <[EMAIL PROTECTED]>
>A: wine-devel@winehq.org
>Sujet: Re: PBuffer and wglMakeCurrent()
>
>Tomas Carnecky wrote:
>> comments?
>>
>
>Why do I have the impression that
sizeof(flags), (LPSTR)&flags )) return False;
+return ((flags & X11DRV_FLAG_PBUFFER) == X11DRV_FLAG_PBUFFER);
+}
+
/***
* wglCreateContext (OPENGL32.@)
@@ -571,8 +581,9 @@ BOOL WINAPI wglMakeCurrent(HD
In wglMakeCurrent(), when the HDC type is OBJ_MEMDC you activate the
frontbuffer for drawing. PBuffers' type is also OBJ_MEMDC, but changing
the drawbuffer in that case is wrong.
Is there a way to find out if the HDC is a PBuffer? I have some patches
in my local tree but I took the freedom t
ork either.
We need to find out what happens to the render state under Windows
when we make call wglMakeCurrent on a bitmap (I know that even with
the rendering state set for GL_BACK then the bitmap gets drawn on) and
whether we restore the rendering context when we switch back to using
som
ourse won't work either.
>
> We need to find out what happens to the render state under Windows
> when we make call wglMakeCurrent on a bitmap (I know that even with
> the rendering state set for GL_BACK then the bitmap gets drawn on) and
> whether we restore the rendering
what happens to the render state under Windows
when we make call wglMakeCurrent on a bitmap (I know that even with
the rendering state set for GL_BACK then the bitmap gets drawn on) and
whether we restore the rendering context when we switch back to using
some other dc afterwards. We probably shoul
Tomas Carnecky wrote:
I don't know if it even runs.. I mean, if it works correctly.
http://dbservice.com/tom/LinuxTest.exe
It creates LinuxTest.log in the same directory as the executable, and
prints out whether pbuffers are supported and which drawbuffers are
activated..
tom
Well, I ra
default the backbuffer is selected for
> rendering), then activates the pbuffer (together with the same context),
> now wglMakeCurrent() calls glDrawBuffer(GL_FRONT_LEFT), so the
> frontbuffer is selected for rendering, and now the application again
> activates the window and now it sudd
Tomas Carnecky wrote:
I have written a test for windows (to test whether wglMakeCurrent
changes the drawbuffer or not), but nobody of my friends has a graphics
card that supportd pbuffers.
tom
I have a GF FX5700. Does that support pbuffers? If so, I'll run the
test
Tom
k, but see what happens if an application has one rendering context,
one window (doublebuffered) and one pbuffer (doublebuffered or not),
activates the window (per default the backbuffer is selected for
rendering), then activates the pbuffer (together with the same context),
now wglMakeCurrent() calls g
On Sat, Mar 25, 2006 at 02:23:01AM +0100, Tomas Carnecky wrote:
> GL_FRONT and GL_FRONT_LEFT mean the same unless the drawable is stereo.
> And I don't think PBuffers or Pixmaps can be stereo, so is there any
> special reason to use GL_FRONT_LEFT ? Or is it because the spec sais so?
See man glXCre
GL_FRONT and GL_FRONT_LEFT mean the same unless the drawable is stereo.
And I don't think PBuffers or Pixmaps can be stereo, so is there any
special reason to use GL_FRONT_LEFT ? Or is it because the spec sais so?
tom
Hi,
> maybe it was because of the earlier opengl patch 'Store GL context in
> TEB'. But I didn't notice such an increase then.. only from ~20 -> ~30fps
Hm.
Something increased the speed of half-life / counter strike drastically. It
isn't your patch, but some change that is in CVS already. The cha
Tomas Carnecky wrote:
> Also, it would be great if we could put the *Swap*Buffers() into their
> own log domain, something like 'swapbuffers', because the trace is
> usually useless, only when you explicitly look whether these functions
> are called or not, otherwise they only fill the log with gar
non-default) pixel format, the IDs
> were 0x21 and 0x23 in my case (glxinfo/xdpyinfo report Visual ID in the
> range from 0x21 to 0x70).
yes, the classic wine problem :(
> But! I've seen that World of Warcraft calls wglMakeCurrent() with a
> darawable that has Visual ID 0x71 a
On Friday 24 March 2006 00:13, Tomas Carnecky wrote:
> Stefan Dösinger wrote:
> > Hi,
> >
> >> So.. in this attachment you'll find a patch that does what I've just
> >> described. I can't test it on anything else than WoW, so if someone
> >> would please review it and test with outher opengl/d3d ap
Stefan Dösinger wrote:
> Hi,
>> So.. in this attachment you'll find a patch that does what I've just
>> described. I can't test it on anything else than WoW, so if someone
>> would please review it and test with outher opengl/d3d applications it
>> would be great.
> No effects noticed with Half-lif
Hi,
> So.. in this attachment you'll find a patch that does what I've just
> described. I can't test it on anything else than WoW, so if someone
> would please review it and test with outher opengl/d3d applications it
> would be great.
No effects noticed with Half-life 1(GL), Warcraft III(GL and D3
om 0x21 to 0x70).
But! I've seen that World of Warcraft calls wglMakeCurrent() with a
darawable that has Visual ID 0x71 and a context with Visual ID 0x21. Now
0x71 is not defined (according to the glxino output) but it works fine,
eg. glXMakeCurrent() doesn't produce the X Error in that
It is accelerated, and it uses Mesa too. If it wasn't, it would say
indirect renderer.
oops, my mistake.. I missed the line "Direct Rendering: Yes"
_
Powerful Parental Controls Let your child discover the best the Internet has
t
On Thursday 16 March 2006 10:21, Wino Rojo wrote:
> Hi Raphael,
>
> >No it's use the "best visual" who match asked capacities
>
> - is this "best visual" the same as the one returned by "glxinfo -b" ?
no the best matching caps asked by wine init
(see X11DRV_setup_opengl_visual on x11drv/opengl.c
On 3/16/06, Wino Rojo <[EMAIL PROTECTED]> wrote:
> Interesting... according to your log file, it seems you are using Mesa
> instead of any ATI accelerated driver.
>
>
It is accelerated, and it uses Mesa too. If it wasn't, it would say
indirect renderer.
Interesting... according to your log file, it seems you are using Mesa
instead of any ATI accelerated driver.
From: "Jesse Allen" <[EMAIL PROTECTED]>
To: "Wino Rojo" <[EMAIL PROTECTED]>
Subject: Re: wglMakeCurrent
Date: Wed, 15 Mar 2006 11:45:16 -0700
>
&g
Hi Raphael,
No it's use the "best visual" who match asked capacities
- is this "best visual" the same as the one returned by "glxinfo -b" ?
- the capacities asked by who? at this point we haven't call
ChoosePixelFormat or SetPixelFormat yet
No your problem don't seems to be here.
can y
Sorry for my late response
but i haven't much time now
> I'm not familiar at all with wine, so I'm not sure how we should fix this
> (but it seems this would fix a lot of opengl related problems)
>
> When we first call X11DRV_setup_opengl_visual, I guess it's using the first
> visual ID.
No it's
See if you can tell from my log:
http://www.chez.com/alors/logfile
Jesse, I can't access your log at that page (I got an error). Could you
please send it to me?
Thanks,
W
_
MSN® Calendar keeps you organized and takes the effo
so, in your system the default visual ID is 0x28, and later my app create
contexts with visual ID 0x23 but everything works fine for you...
ok, back to square one :-(
_
Powerful Parental Controls Let your child discover the best th
On 3/15/06, Wino Rojo <[EMAIL PROTECTED]> wrote:
> Ok, so now we know what's is going on here :-)
>
> I'm not familiar at all with wine, so I'm not sure how we should fix this
> (but it seems this would fix a lot of opengl related problems)
>
> When we first call X11DRV_setup_opengl_visual, I guess
Ok, so now we know what's is going on here :-)
I'm not familiar at all with wine, so I'm not sure how we should fix this
(but it seems this would fix a lot of opengl related problems)
When we first call X11DRV_setup_opengl_visual, I guess it's using the first
visual ID. But later, when we cre
On 3/15/06, Wino Rojo <[EMAIL PROTECTED]> wrote:
> Hi Jesse,
>
> That's very interesting... Yes, I'm using a nvidia card. I think I know the
> reason why is working for you but not for me
>
> glxinfo tells me that my first visual ID is 0x21. However, on some ATI cards
> glxinfo reports 0x23 as the
Hi Jesse,
That's very interesting... Yes, I'm using a nvidia card. I think I know the
reason why is working for you but not for me
glxinfo tells me that my first visual ID is 0x21. However, on some ATI cards
glxinfo reports 0x23 as the first visual, which is the same visual ID of the
context
roposed in those patches, but it didn't work :-(
>
> After further inspection, it seems the problem is when I call wglMakeCurrent
> for a context which shares display lists with another context. I've attached
> the program and the source code, so you can try it.
>
>
> As
seems the problem is when I call wglMakeCurrent
for a context which shares display lists with another context. I've attached
the program and the source code, so you can try it.
This is the output of the trace+opengl:
trace:opengl:has_opengl GLX is up and running
On 3/13/06, Wino Rojo <[EMAIL PROTECTED]> wrote:
> Hi
>
> I'm pretty new to wine, and this is my first post to the wine-devel
> listI hope this is the correct place to send my question
>
> I'm having problems with wglMakeCurrent. I wrote a small OpenGL te
Wino Rojo wrote:
> Hi
>
> I'm pretty new to wine, and this is my first post to the wine-devel
> listI hope this is the correct place to send my question
>
> I'm having problems with wglMakeCurrent. I wrote a small OpenGL test
> program, but it's not working
On Mon, Mar 13, 2006 at 01:00:08PM -0500, Wino Rojo wrote:
> X Error of failed request: BadMatch (invalid parameter attributes)
> Major opcode of failed request: 144 (GLX)
> Minor opcode of failed request: 5 (X_GLXMakeCurrent)
> Serial number of failed request: 120
> Current serial number
Hi
I'm pretty new to wine, and this is my first post to the wine-devel
listI hope this is the correct place to send my question
I'm having problems with wglMakeCurrent. I wrote a small OpenGL test
program, but it's not working under wine (it works perfectly on Windows
В сообщении от 26 Август 2005 15:32 Lionel Ulmer написал(a):
> On Wed, Aug 24, 2005 at 02:40:48PM -0700, Russ wrote:
> > Under WINE, the subwindow graphics all get drawn in the
> > lower left corner of the overall X11 window, and the entire X11 window's
...
> So we have two possible solutions:
>
>
On Wed, Aug 24, 2005 at 02:40:48PM -0700, Russ wrote:
> Trying to get my 3-D app to run under WINE using the same binary with the odd
> workaround or two. It uses OpenGL in various subwindows of the main window as
> needed. Under WINE, the subwindow graphics all get drawn in the lower left
> corner
ower left
> corner of the overall X11 window, and the entire X11 window's redraw is
> mangled---OpenGL is affecting the entire X11 Window.
>
> In Win32, when you call wglMakeCurrent, the opengl context is configured to
> match the size/position of the HWND for the HDC, even if it is on
x27;s redraw is
mangled---OpenGL is affecting the entire X11 Window.
In Win32, when you call wglMakeCurrent, the opengl context is configured to
match the size/position of the HWND for the HDC, even if it is only a small
child window, so drawing openGL goes just into the desired subwindow. However,
the
call
wglMakeCurrent, the opengl context is configured to match the size/position of
the HWND for the HDC, so drawing openGL goes just into the desired subwindow.
However, the WINE implementation of wglMakeCurrent just calls glXMakeCurrent
(and glXCreateContext), which produces the entire size of the
58 matches
Mail list logo
