EGL support

[kvark]

Could this generator be used to generate EGL bindings?

[Lokathor]

It could be expanded to do so, but currently it is intended for gl.xml only. I suspect egl.xml is very similar, but I'm not familiar with the specifics.

[kvark]

What's the next step here? Do you intend to try it out any time soon, or expect me to start hacking on that? Problem is that I don't know how much effort that would take, and even whether this is in scope for this library,

[Lokathor]

I am totally unfamiliar with egl.xml, but since you (i think) are still just matching up with C function calls it should be able to share most of the logic. It's WebGL that binds to javascript instead of C, right?

I can have a look at it tomorrow and give you a better idea if you want, or you could just push ahead on your own.

Personally I use the crate more as a binary, so if the binary program just detected when it was running on a gl.xml or egl.xml and completely adapted the rest of the command line args appropriately that'd be fine. If you wanted it to be available in a more library-like way that works too probably.

[kvark]

Yes, my tentative plan was to create a gfx-egl crate with a Makefile that calls phosphorus with proper arguments to update the source, so I'm only interested in command line. Appreciate you looking at it tomorrow, thank you!

[Lokathor]

Having looked at the egl.xml file, I'd say that most of the logic from the gl.xml handling would be transferable. However, you'd need to do some new work as well. For example, the types parsing has never been fully general, and in the complex case it just falls back to reading the entire input string and then matching against an expected value to produce a "known correct" output value.

I think that once the parser is adjusted, most of the logic of what code to print out for EGL should be very close to the logic for what to print for GL, of course other than stuff being prefixed "EGL" instead of "GL".

I don't have the time lately to work on this sort of thing, but you could do the PR and I'd merge it in.

[kvark]

What if I want a very specific set of bindings? Only a subset of entry points and constants, only stuff the gfx backebd would need, for example? Does (or will) phosphorus be able to make that?

On Nov 8, 2020, at 13:05, Lokathor [email protected] wrote:

 Having looked at the egl.xml file, I'd say that most of the logic from the gl.xml handling would be transferable. However, you'd need to do some new work as well. For example, the types parsing has never been fully general, and in the complex case it just falls back to reading the entire input string and then matching against an expected value to produce a "known correct" output value.

I think that once the parser is adjusted, most of the logic of what code to print out for EGL should be very close to the logic for what to print for GL, of course other than stuff being prefixed "EGL" instead of "GL".

I don't have the time lately to work on this sort of thing, but you could do the PR and I'd merge it in.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Lokathor]

It might take a few extra lines of code, but that's totally possible.

The basic workflow of the binary is:

• Parse A File: This gives you a bunch of piles of stuff. Importantly you get some Types, Enumerations, and Commands, and you also get some Feature and Extension descriptions.
• Make Your Selection: This is where you use a Feature level as well as your Extensions to pick what Types, Enumerations, and Commands will actually appear in the output. Think of it as a "filter" operation.
• Print The Selections: This is where the huge piles of stuff get dumped to a file or stdout or wherever.

So you should be able to adjust the Selection process to pick only exactly the items you want after it's all been parsed in.

Note that having extra Type and Enumeration entries you don't use has no runtime effect, but having extra Commands does because it'll still load those pointers and store them so it'll take up a hair more memory (either as AtomicPtr statics or as files on the struct of loaded pointers).

[Lokathor]

@kvark For the next big version, the crate will become less automatic about reading the XML every time. Instead, I'm just going to automate a majority of the XML reading and then hand-edit parts at the end. Then when the XML updates I'll just check the diff and apply any changes by hand. GL is a pretty static API anyway so it's not a big deal.

So, in other words, while I intend to support most or all of gl.xml, if you only need a few bits of egl.xml, if you just tell me which bits you want then I can probably just put in a few bonus functions under a feature flag or whatever.

(assuming you still need egl support)

[kvark]

List of entry points we need today:

• choose_first_config
• query_string
• get_configs/get_config_count
• get_config_attrib
• bind_api
• create_context
• create_pbuffer_surface
• destroy_context
• terminate
• get_platform_display
• get_display
• create_platform_window_surface
• swap_buffers

[Lokathor]

oh that all sounds small enough to do by hand just the once.