NVidia handle signatures

[GoogleCodeExporter]

The NvDisplayHandle and NvPhysicalGpuHandle structs found in NVAPI.cs are 
invalid in comparison with the NvApi header, all references for these two 
structures should be replaced with IntPtr. As an added bonus this will also 
reduce runtime allocations and overhead from calling the NvApi consecutively.

Original issue reported on code.google.com by dmex04@gmail.com on 1 Jan 2011 at 2:07

[GoogleCodeExporter]

As far as I know there is no typedef in C#, so I can't create directly a new 
value type identical to IntPtr. That's why I used the struct workaround to 
create new custom value types of the size of IntPtr. So I don't see why the 
current solution is invalid.

Of course one could as well use IntPtr everywhere, but then there is no 
difference in type between NvDisplayHandle and NvPhysicalGpuHandle. The current 
solution prevents usage of NvDisplayHandles in places where a 
NvPhysicalGpuHandle would be expected (vice versa).

I am not sure what overhead is produced by the current solution in machine 
code. I expect it not to be large, but so far I did not analyze it. Is it 
measurable?

Original comment by moel.mich on 1 Jan 2011 at 5:13

• Changed state: NeedsInfo

[GoogleCodeExporter]

IntPtr is a structure created on the stack, wrapping an IntPtr with another 
structure would only as you said prevent usage of one handle where another is 
expected, the CLR is actually making your definition work through marshaling as 
it uses the first field of the structure at offset 0 sizeof IntPtr which is 
what the NvApi signature is expecting. Performance wise the measurable overhead 
is x * query, 1 structure * 60 seconds, GC has to clear these from memory which 
causes more time in GC which pauses all the threads to preform this work...You 
can visually see the GC overhead created by grabbing the titlebar and moving 
the window in a clockwise or anti-clockwise direction, Instead of being a fluid 
motion, It will jump around.

btw, C# does have something similar to typedef, you have to declare it under 
your namespace declarations, something like 'using NvDisplayHandle = 
System.IntPtr', this must be done in every file, Typesafe and no extra 
overhead. 

using System;
using System.Collections.Generic;
using NvDisplayHandle = System.IntPtr;
using NvPhysicalGpuHandle = System.IntPtr;

Original comment by dmex04@gmail.com on 2 Jan 2011 at 2:16

[GoogleCodeExporter]

NvDisplayHandle and NvPhysicalGpuHandle are structs (valuetypes), so I would 
expect them to end op on the stack and not on the heap (same as with IntPtr). 
So there shouldn't be any GC overhead. The only overhead I see is in the 
marshaling itself. But I am not sure if there is really any overhead created 
there (that doesn't get optimized away), this is something one would have to 
try and measure.

The jumping of the window when dragging is not caused by the GC, but by the 
sensors update running in the windows.forms thread as far as I remember. It is 
running in the windows.forms thread to avoid the multithreading and the 
Control.Invoke mess for events caused by the sensor updates. 

The "using NvDisplayHandle = System.IntPtr" solution does not give any 
additional type safety as there still is only one type: System.IntPtr. You can 
assign a variable declared with NvDisplayHandle to a variable declared with 
NvPhysicalGpuHandle (as both are of the same type obviously).

Original comment by moel.mich on 2 Jan 2011 at 2:44