We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 88 - DirectX refresh rate patch + graphics freeze patch
Summary: DirectX refresh rate patch + graphics freeze patch
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: don't know
Hardware: x86 Windows (All)
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-27 00:13 UTC by Sam Lantinga
Modified: 2006-01-30 07:40 UTC (History)
1 user (show)

See Also:

Attachments
sdl_dx5video.diff.txt (4.24 KB, patch)
2006-01-27 00:14 UTC, Sam Lantinga 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sam Lantinga 2006-01-27 00:13:38 UTC 
Date: Sat, 31 Jan 2004 23:47:36 +0300
From: Dmitry Yakimov <support@activekitten.com>
Subject: [SDL] Re: Minimal SDLLoop using SDL_GL_Swapbuffers freezes gfx

Hi,

I was wrong, my patch does not fix that.
The root of the problem is the same as in case of freeze while 2D
hardware page swapping. If we execute SwapBuffers without any delay
between calls, OpenGL driver should wait until hardware completes
previous frame. Driver is executed in ring0, so when it waits it
freezes all the system :-) It's better to wait in user code rather
than in driver code. That's why I wrote the patch for the same
behavior in 2D.
Comment 1 Sam Lantinga 2006-01-27 00:14:10 UTC 
Created attachment 43 [details]
sdl_dx5video.diff.txt
Comment 2 Ryan C. Gordon 2006-01-27 11:23:26 UTC 
Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.
Comment 3 Dmitry Yakimov 2006-01-27 12:10:45 UTC 
We already added this patch.
But interesting - using the last part of patch - waiting in user code might drain batteries on notebooks. So now I do not know what evil choose - either very rary freezes or draining batteries :) Although good programmer should limit FPS manually by applying Sleep API.

--Dmitry.