You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reported in version: 1.2.13 Reported for operating system, platform: Linux, x86
Comments on the original bug report:
On 2009-02-10 10:06:15 +0000, Simon Williams wrote:
Code:
// The line is optional. Same thing happens if you leave it unset.
SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 0);
// Initialise video with SDL_OPENGL here.
int v;
SDL_GL_GetAttribute(SDL_GL_SWAP_CONTROL, &v);
// v is now 1. WTH?
In my program I can tell if this is actually set or not because I get obvious tearing without it.
This happens with other GL attributes as well, including (but not limited to): SDL_GL_DOUBLEBUFFER and SDL_GL_ACCELERATED_VISUAL.
On 2009-09-13 16:33:27 +0000, Ryan C. Gordon wrote:
Tagging this bug with "target-1.2.14" so we can try to resolve it for SDL 1.2.14.
Please note that we may choose to resolve it as WONTFIX. This tag is largely so we have a comprehensive wishlist of bugs to examine for 1.2.14 (and so we can close bugs that we'll never fix, rather than have them live forever in Bugzilla).
--ryan.
On 2009-09-18 11:31:24 +0000, Rene Dudfield wrote:
Hi,
This is documented behaviour of the function:
"You should use SDL_GL_GetAttribute to check the values after a SDL_SetVideoMode call, since the values obtained can differ from the requested ones."
So you need to check the value that you are trying to set... to see if it is set as requested or not.
Closing bug.
cheers,
On 2009-09-18 13:26:15 +0000, Simon Williams wrote:
(In reply to comment # 2)
This is documented behaviour of the function:
"You should use SDL_GL_GetAttribute to check the values after a
SDL_SetVideoMode call, since the values obtained can differ from the requested
ones."
So you need to check the value that you are trying to set... to see if it is
set as requested or not.
Closing bug.
Did you even read my report? What does it look like I'm trying to do with it? I call SetAttribute to set something, and then use GetAttribute to see if it worked. GetAttribute always reports that it is set, even in all these cases where it should show unset:
SetAttribute was told to set the attribute, but failed.
SetAttribute was told to unset the attribute, so it really is unset.
Setattribute was never called to touch that attribute (the default is unset).
Why exactly did you close this bug?
On 2009-09-18 13:28:54 +0000, Simon Williams wrote:
(In reply to comment # 2)
How exactly is "returning set even when it's unset" the documented behaviour?
On 2009-09-18 14:21:37 +0000, Rene Dudfield wrote:
Hello,
I closed the bug, as from your description it looked to me like it's behaving as it should. Sorry about that... but now it's opened again :).
I still think it's behaving as documented. If your gl system is reporting it's set as something and doing something else I'm not sure if that's an error with this function or not. Since it's a hint, it's within its rights to do what it likes... I think.
What does examples/testgl.c print out for you?
Also, do you check for errors after the call? The return value is -1 on error and an error is set. I think you also have to set v to something before you make the call - otherwise v can be uninitialised in the case where there's a failure. Maybe that's the problem.
eg.
int v = 0;
if( SDL_GL_GetAttribute(SDL_GL_SWAP_CONTROL, &v) == -1 ) {
... print error message.
} else {
}
On 2009-09-21 16:49:59 +0000, Simon Williams wrote:
Created attachment 370
testgl.c results
On 2009-09-21 16:55:23 +0000, Simon Williams wrote:
(In reply to comment # 5)
I still think it's behaving as documented. If your gl system is reporting it's
set as something and doing something else I'm not sure if that's an error with
this function or not. Since it's a hint, it's within its rights to do what it
likes... I think.
If GL is at fault then fine.
What does examples/testgl.c print out for you?
See attached file in previous post.
Also, do you check for errors after the call? The return value is -1 on error
and an error is set. I think you also have to set v to something before you
make the call - otherwise v can be uninitialised in the case where there's a
failure. Maybe that's the problem.
eg.
int v = 0;
if( SDL_GL_GetAttribute(SDL_GL_SWAP_CONTROL, &v) == -1 ) {
... print error message.
} else {
}
AHA! I did not know about this. I initialised v to 2 and called GetAttribute and lo and behold it was still 2. GetAttribute is indeed returning -1 when asked to get SDL_GL_SWAP_CONTROL. SDL_GetError() says "OpenGL attribute is unsupported on this system".
This is very strange. If I don't set SDL_GL_SWAP_CONTROL, or set it to 0, my application has very visible tearing. If I call SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 1) then this goes away.
So we can set SWAP_CONTROL but not read the state of it? Is this SDL's fault or GL's?
On 2009-09-21 16:59:51 +0000, Simon Williams wrote:
(In reply to comment # 7)
Further to my last comment...
Calling SetAttribute with SDL_GL_SWAP_CONTROL does not give an error.
Calling Set or Get on other attributes (SDL_GL_DOUBLEBUFFER, SDL_GL_ACCELERATED_VISUAL) work as expected without errors or unchanged variables.
On 2009-09-22 12:24:59 +0000, Rene Dudfield wrote:
"SDL_GL_SetSwapInterval doesn't work with nvidia drivers".
Where the the swap interval does not work for nvidia drivers (another others using that extension).
I don't think SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 1) should give an error or not if it doesn't work. I think it's supposed to be a hint.
So closing this bug, with the other bug to get swap control working with nvidia open still.
cheers,
On 2009-09-22 14:58:05 +0000, Simon Williams wrote:
(In reply to comment # 9)
I'm not sure about that. That bug is about setting swap control. As I have said before, I have no problems with setting it. In fact, I have clearly visible results showing that SWAP_CONTROL is set or not, which are entirely dependant on whether I called SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 1) or not.
The issue I have is with getting the state of the swap control. Maybe it is related to the other bug, but from what I can tell the other bug implies that calling Set on SWAP_CONTROL shouldn't do anything. This is clearly not the case.
On 2009-09-29 06:19:40 +0000, Ryan C. Gordon wrote:
I'm reopening this one...the reason this fails is because we think the swap_control extension doesn't exist unless the Mesa version is used. The SGI version works correctly in SetAttribute, but we don't check for it in GetAttribute.
(The SGI version doesn't have an equivalent of glXGetSwapIntervalMESA(), but we can just return a successfully set value here.)
--ryan.
On 2009-09-29 06:51:46 +0000, Ryan C. Gordon wrote:
This should be fixed in svn revision # 4893, but I need someone to confirm, as I don't have appropriate test hardware at the moment.
--ryan.
On 2009-10-09 22:42:53 +0000, Ryan C. Gordon wrote:
Tested with Nvidia's Linux drivers here, this is fixed.
--ryan.
The text was updated successfully, but these errors were encountered:
This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:
Reported in version: 1.2.13
Reported for operating system, platform: Linux, x86
Comments on the original bug report:
On 2009-02-10 10:06:15 +0000, Simon Williams wrote:
On 2009-09-13 16:33:27 +0000, Ryan C. Gordon wrote:
On 2009-09-18 11:31:24 +0000, Rene Dudfield wrote:
On 2009-09-18 13:26:15 +0000, Simon Williams wrote:
On 2009-09-18 13:28:54 +0000, Simon Williams wrote:
On 2009-09-18 14:21:37 +0000, Rene Dudfield wrote:
On 2009-09-21 16:49:59 +0000, Simon Williams wrote:
On 2009-09-21 16:55:23 +0000, Simon Williams wrote:
On 2009-09-21 16:59:51 +0000, Simon Williams wrote:
On 2009-09-22 12:24:59 +0000, Rene Dudfield wrote:
On 2009-09-22 14:58:05 +0000, Simon Williams wrote:
On 2009-09-29 06:19:40 +0000, Ryan C. Gordon wrote:
On 2009-09-29 06:51:46 +0000, Ryan C. Gordon wrote:
On 2009-10-09 22:42:53 +0000, Ryan C. Gordon wrote:
The text was updated successfully, but these errors were encountered: