LCL and low level screen routines

[howardpc]

Does the LCL have a way to discover the screen refresh rate?
And if so, is there a way to synchronise timed code with onset of screen refresh, or is the synchronised calling of Paint outside programmer control (an Invalidate call might be followed by several ms delay before the display is updated) ?

[AlexTP]

LCL cannot detect the refresh rate. Paint occurs at any rime.

[MarkMLl]

Does the LCL have a way to discover the screen refresh rate?
And if so, is there a way to synchronise timed code with onset of screen refresh, or is the synchronised calling of Paint outside programmer control (an Invalidate call might be followed by several ms delay before the display is updated) ?

On what OS? On what kind of hardware? What makes you think that there really is such a thing as a refresh rate these days?

I think a more useful question would be the latency between a command being sent to Windows or X11 etc., and the image on the LCD changing. But these days there is such a vast number of intervening alphabet soup that it is effectively unanswerable.

MarkMLl

[jamie]

in windows you can detect this info.

[dje]

EDIT: My understanding of OpenGL's SwapBuffer is that it will sync with the display, so, no matter how hard you try to call it, you wont get a FPS higher than the display rate.

I answer these types of questions by finding out how such a feature would be implemented, and then search the FPC/Lazarus source code for the commands used.
Under Windows you have: (EnumDisplaySettings)
https://stackoverflow.com/questions/4110731/how-to-get-the-screen-refresh-rate
Under Unix style OS's (X11) you have: (XRRGetScreenInfo/XRRConfigCurrentRate)
http://rpm.pbone.net/manpage_idpl_34102865_numer_3_nazwa_XRRGetScreenInfo.html

I searched the FPC/Lazarus code and I couldnt find a cross platform wrapper for this feature. So, you can either search other libraries, or you must code the feature for each OS you want to support:

Example: This returns 60 on my Raspberry Pi:

Code: Pascal  [Select][+][-]

1. uses xrandr, x, xlib;
2.  
3. function GetCurrentRate: integer;
4. var
5.   LDisplay: PXDisplay;
6.   LRootWindow: TWindow;
7.   LScreenInfo: PXRRScreenConfiguration;
8. begin
9.   LDisplay := XOpenDisplay(nil);
10.   LRootWindow := RootWindow(LDisplay, 0);
11.   LScreenInfo := XRRGetScreenInfo(LDisplay, LRootWindow);
12.   Result := XRRConfigCurrentRate(LScreenInfo);
13.   XCloseDisplay(LDisplay);
14. end;    

Some people also like to call the commandline tool xrandr to get/set screen settings. This may suit you:

https://www.khronos.org/opengl/wiki/Programming_OpenGL_in_Linux:_Changing_the_Screen_Resolution

[MarkMLl]

Example: This returns 60 on my Raspberry Pi:

...which is connected via HDMI, which still has vestiges of line and frame sync. at least in the earlier versions which were a superset of DVI.

But what of a direct connection on an LCD etc.? My vague recollection is that FPD (and possibly the variant of LVDI which replaces it) still basically sends out the entire screen buffer repeatedly, but I don't think it's safe to rely on any sort of "blanking interval" existing or being accessible.

Not to mention problems where one LCL window is split between two physical displays: even if the apparent frame rate is the same they're not going to be in sync unless- IIRC- you have some expensive Nvidia rig intended for 3D.

In any event, I'm not convinced that any of this is really meaningful any more since a display controller will either have multiport memory or will go to substantial pains to simulate it.

MarkMLl