GLFW should be extended

[realvictorprm]

I think even tough GLFW is here used for Vulkan that it would be nice to complete it.
For example I'm using it for Vulkan and would like to use it for OpenGL too. However in the current state this wouldn't be possible.

I'll extend the glfw3.cs file to be capable of using OpenGL too.

-EDIT-
I also would suggest to integrate this existing library (which is maybe outdated).
It's licensed under MIT too:
https://github.com/lodicolo/glfw-net/tree/master/glfw-net

[FacticiusVir]

That's fair; it's worth doing but as it doesn't feed directly into Vulkan it wasn't high on the priority list. I'll need to review the library, but of the GLFW code I could find on NuGet none had implementations of the Vulkan-specific functions

[realvictorprm]

I found out so too. Could we make a xml which specifies the wrapper around glfw too? That's what I thought about.

[FacticiusVir]

XML in the style of vk.xml for spec publishing, or XML containing code comments in the build output?

[realvictorprm]

Something like the vulkan hpp generator

[FacticiusVir]

Do you have a link?

[realvictorprm]

https://github.com/KhronosGroup/Vulkan-Hpp

[realvictorprm]

Either we do it with something like VulkanHpp or we merge the existing wrapper library with ours. However it requires of course, that the library would depend on SharpVk too because of functions like glfwGetWindowSurface(...).

PS:
I've to correct myself. I think of doing it with GLFW the same way you have done with Vulkan. Automatic generation of the wrapper.

[FacticiusVir]

Sorry, I meant a link to the XML file; the only one I can see is vk.xml imported from Vulkan-Docs (https://github.com/KhronosGroup/Vulkan-Docs/blob/1.0/src/spec/vk.xml). It would be useful to have a base XML like vk.xml for GLFW from which to generate bindings, but as the GFLW API doesn't change very often it doesn't seem worth the time required to write the XML and a generator instead of just hand-coding the C# bindings.

[realvictorprm]

Okay @FacticiusVir. Then we do it on the old way. Manual writing 👍
So far I suggest forking the library I mentioned in beginning (refresh it to newest GLFW) and change the bindings of SharpVk.GLFW so that it is in the same namespace like the existing library.

[FacticiusVir]

Sure, will have a look at it tonight

[realvictorprm]

Hey @FacticiusVir I've decided to make an auto generator for GLFW and added you to gitter chat of the repository. I think this could be a valid solution for our problem with the up-to-date GLFW binding. What do you think?

[realvictorprm]

Hello again @FacticiusVir!
The binding is nearly complete but already ready for usage in SharpVk. Unfortunately I would need access to the Handle of the Instance and the Surface to provide an easy integration. Could we try to calibrate our libraries?

PS:
What do you think, could we make GLFW3.NET for surface creation as official library for your binding?

[FacticiusVir]

The raw value of all handle types is exposed; e.g. for Instance. You can see it being used here. There is also a specific method for creating Surface objects from an external handle.

[realvictorprm]

Perfect @FacticiusVir. I'll commit some examples of how-to-use SharpVk with GLFW3.NET .

Feel free to reference my binding for your binding 😃

[FacticiusVir]

Hey, so I've had a look over your library, and I think for the time being I'm going to stick with the internal implementation - in truth, full GLFW3-coverage isn't high enough a priority to merit an additional dependency.
I'll certainly keep an eye on the project as you progress; and if I might also offer some suggestions:

• Compare GLFWvidmode with VideoMode - for a simple data structure, you have to create and dispose a heap object & the native copy, which causes heap allocations & potential GC churn along with a risk of memory leaks.
• GLFWgammaramp is straight-up exposing pointers to data, requiring calling code to support unsafe contexts.
• Vulkan handle/struct types are defined again in GLFW3.NET, so even if you supply Vulkan binding-specific extensions to handle the type-conversions you're adding more heap allocations.
• The next version of SharpVk is being built against .NET Standard and the samples will be following suit, so any dependencies would also need to build against .NET Standard targets, including PInvoke mappings for non-Windows platforms. Note this method especially which won't work on Mono, as the underlying pointer layout is different.
  Thanks again!

[realvictorprm]

To your points:

1. There shouldn't happen any leaks simply because CppSharp generates normaly only bindings which are leak free.
2. Yeah the generated code isn't everytime completly user friendly.
3. After I experimented a bit I decided to remove them. They are not needed, ptr's are enough.
4. The reinterpret cast shouldn't be used at all. Im aware of this issue so I'm working on solving this. Afterwards it's solved I'll make a nuget package

Thanks for feedback @FacticiusVir 😃 👍 !