For some reason on the toshiba laptop from 2012 the opengl driver loads very slowly. (Toshiba laptop L670 2012/Intel/AMD/RadeON)

So slow that I believed the application "frooze/hang" but this is not the cause.

Possible causes:

1. I "hacked" the driver version number to try and make Star War Battlefront 2 run.
2. AMD installed a bad driver, or sabotaged the laptop trying to make it run slow.
3. Microsoft fucked up and installed some bad driver to make the laptop run slow.
4. The slow 5200 RPM harddisk is responsible for the slow load. Though 80 MB/sec should be enough ?!

It's suspicious at the very least.

My question is: Is there a programmatic way to tell how long it will take to load the opengl driver ? Is there a way to tell when it's done, besides from ofcourse the rendering suddenly kicking in.

I did a quick google and find two threads that might be of some interesting:

https://docs.microsoft.com/en-us/windows-hardware/drivers/display/loading-an-opengl-installable-client-driver

"
The OpenGL runtime accesses the registry to determine which OpenGL installable client driver (ICD) to load.

To load the OpenGL ICD, the OpenGL runtime:

Determines the name, version, and flags that are associated with the OpenGL ICD by calling the

D3DKMTQueryAdapterInfo function with the KMTQAITYPE_UMOPENGLINFO value set in the Type member of the

D3DKMT_QUERYADAPTERINFO structure that the pData parameter points to.

Checks the version number of the OpenGL ICD that D3DKMTQueryAdapterInfo returns to validate the version

of the OpenGL ICD.

Loads the OpenGL ICD by using the name of the OpenGL ICD.

Initializes access to the OpenGL ICD's functions. Note To obtain a license for the OpenGL ICD

Development Kit, contact the OpenGL Issues team.

To locate the name of the OpenGL ICD, D3DKMTQueryAdapterInfo searches the registry in the following key:
registry

HKLM/System/CurrentControlSet/Control/Class/{Adapter GUID}/0000/

This key also contains the names of the Microsoft Direct3D user-mode display drivers. This key contains four

registry entries for 32-bit Windows Vista display drivers that are used on 32-bit Windows Vista and four

entries for 32-bit Windows Vista display drivers that are used on 64-bit Windows Vista. The following entries

are for 32-bit Windows Vista display drivers that are used on 32-bit Windows Vista:

UserModeDriverName
REG_SZ

The name of the Direct3D user-mode display driver, which is required for the operation of a Direct3D

rendering device regardless of whether the operating system supports an OpenGL ICD.

OpenGLDriverName
REG_SZ

The name of the OpenGL ICD. For example, if the OpenGL ICD is Mydriver.dll, the value of this entry is

Mydriver.dll.

OpenGLVersion
REG_DWORD

The version number of the OpenGL ICD that the OpenGL runtime uses to validate the version of the OpenGL ICD.

OpenGLFlags
REG_DWORD

A flag bitmask. Currently, bit 0 (0x00000001) is set for compatibility. When bit 1 (0x00000002) is set, the

OpenGL runtime does not call the ICD's finish function before the runtime calls the ICD's swap-buffers

function.

The following entries are for 32-bit Windows Vista display drivers that are used on 64-bit Windows Vista:

UserModeDriverNameWow
REG_SZ

The name of the 32-bit Microsoft Direct3D user-mode display driver for 64-bit Windows Vista.

OpenGLDriverNameWow
REG_SZ

The name of the 32-bit OpenGL ICD for 64-bit Windows Vista.

OpenGLVersionWow
REG_DWORD

The version number of the 32-bit OpenGL ICD for 64-bit Windows Vista.

OpenGLFlagsWow
REG_DWORD

A flag bitmask of the 32-bit OpenGL ICD for 64-bit Windows Vista.
"

and this:

https://stackoverflow.com/questions/66089533/how-does-the-opengl-function-loading-mechanism-work

Has anybody ever developed a "loading opengl driver" window/display ?

I could place a label behind the render window and tell the user:

"please wait for the opengl driver to load".

Bye for now,
Skybuck.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Here is some more information after running DBG Spider on it:

Short conclusion:

It might be some application code problem, maybe even a Delphi VCL problem, not yet sure.

What the debugger/profiler is showing is something like this:

TOpenGLControl.WMCreate

TControl.WndProc

TWinControl.WndProc

TWinControl.CreateWindowHandle

TWinControl.CreateHandle

TWinControl.UpdateShowing

TWinControl.UpdateControlState

TWinControl.CMVisibleChanged

TControl.Perform

TControl.SetVisible

Classes.StdWndProc

Windows.CreateWindowEx

Game.initialization

Be advise this is not a call stack, but these functions seems to be calling each other.

TOpenGLControl.WMCreate is code I wrote.

What I believe might be happening is that these functions are calling each other repeatedly in some kind of loop or circle.

Surprisingly no stack overflow occurs.

Apperently this loop continues until somehow it gets out of it. Perhaps by a lucky change of events in windows or perhaps some condition is met.

This is my best bet for now.

Bye for now,

Skybuck.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I found and consulted my older postings about this, fortunately those still on google newsgroups.

GetDC doesn't work well in design state it's value is always different between api calls and such.

So for now I have decided to implement it this way:

function TOpenGLControl.GetDeviceContext : HDC;
begin
if not (csDesigning in ComponentState) then
begin
result := GetDC(Handle);
end else
begin
result := Canvas.Handle;
end;
end;

And then in whatever code a device context is necessary it calls this function:

GetDeviceContext.

The only drawback so far is that it crashes the IDE when the topengl control is put on a form, why exactly I don't know but it might have something to do with the IDE not being able to find the source code or whatever.

I like adding those manually to projects. It could also be some new bug in the IDE, after the project is fixed by adding the graphics units and saved and re-opened all should work fine.

Now I go test it further by re-compilg some of my applications and corona game to solve this weird slow startup hopefully once and for all because it's quite annoying.

It could also be that VCL has a bug which gets more severe as the CPU speed increases !

So Delphi creator be warned and debug your VCL better ! In some rare cases it can behave strangely, still haven't found the exact cause of it... so far so good though...

It may also have to do something with critical sections being locked and unlocked.

Or maybe it trips up the dbg spider...

I am still not 100% convinced this solves it once and for all but it does make the situation better.

It could also be a weird bug in windows 7 home edition or in AMD/ATI driver which is beta, but also the official driver also showed some behaviour.

And same behaviour also noticed on PC/nvidia... windows 7 ultimate edition...

So the mystery remains somewhat but is now less severe.

Bye for now,
Skybuck.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)