[ Return to Bugs & Features ]

STR #1373

Trouble Report Files:

	Name/Time/Date	Filename/Size
	#1  wavexx 07:18 Jul 28, 2006	fltk-vsync.patch 1k

Trouble Report Comments:

	Name/Time/Date	Text
	#1  wavexx 07:18 Jul 28, 2006	[see http://www.fltk.org/str.php?L1370] At least on OSX, you can control whether a given AGL context is vsync-ed or not. This patch adds a vsync() method to Gl_Window which can be issued on a shown (or current) window to enable/disable vsync.
	#2  matt 13:32 Aug 19, 2006	We currently have a feature stop on FLTK 1.1 and fix only bugs. Also, this feature, if it would be implemented, should have safe implementations on all platforms. On X11 and Win32 however, this function does not exist for every driver. Finally, you do have access to everything needed to call this function from within your own application and without changes to FLTK.
	#3  wavexx 07:52 Aug 20, 2006	Yes, there's only changes relative to OS X currently, but I'm planning to complement them for at least WIN32 in the following months as soon as I start to work on it. Consider that even under OS X not all drivers support this feature, and, even if it exists, it may not be effective. This is expected. vsync() only hints the context. If the system or the driver does not support it, it returns -1 (I was looking of some sort of tri-state enum in Enumerations but didn't find any). There's a general tendency to disable vsync by default on today's drivers, which is simply stupid. On my applications I need to at least try to enable it for real-time visuals where it can be enabled non-globally, and I didn't want to put any platform specific code on the application itself or add an intermediate layer for simpler tasks. I also guess that such trivial code may also be useful to any serious application writer using OpenGL. I didn't expect this (and the context_valid) changes to be applied to 1.1 anyway. I've filed them under 1.1 because I'm not following FLTK2 development right now. I will just continue to patch my FLTK build with all the custom changes I need to remove os-specific code in the application themselves where necessary. I can use the newsgroups in the future if filing an STR is inappropriate.
	#4  matt 06:03 Aug 24, 2006	Hi wavexx. I am a long time OpenGL (hey, Iris GL even) monkey and know everything about the benefits of synching with the VBlank. I like your addition, but at this point in development (1.1.8 is getting close), I am extremely careful about breaking code. So I modified this STR (yes, filing an STR is absolutely right) to be a modification for 1.2. That way, it'll either get implemented in 1.2, if it ever happens, or it'll get up'ed to 2.0 eventually (if 1.2 gets abandoned for good).
	#5  wavexx 07:28 Aug 24, 2006	I agree. I might as well share here my notes when I was trying to implement this change. I initially tought that a mode() parameter (like FL_DOUBLE | FL_VSYNC) would be much more convenient to the programmer instead of setting vsync after each context invalidation. Unfortunately, OSX and WIN32 doesn't seem to allow to query vsync status without a context first. Enabling this bit afterwards would clash with mode listings since vsync virtually exists in both statuses with every mode. Maybe handling vsync status internally (ie: restoring requested vsync status automatically on context invalidation) would make more sense instead without messing with modes. Note that Apple's GLUT allows to set global preferences for GLUT applications, which includes vsync status. Very handy. Maybe instead of specifying 10 env vars we should copy this idea or use some kind of unified method without requiring files.
	#6  wavexx 04:20 May 20, 2008	If someone can comment one the API a bit, I can try to implement the same change for win32.
	#7  matt 05:05 Nov 29, 2023	Fixed in Git repository.

[ Return to Bugs & Features ]