Fyne: Add support for OpenGL ES

[andydotxyz]

This is required to support mobile and web targets - and should not provide any issue for the desktop driver.

[xlab]

I hope this migration could be used to standardise rendering backends, like imgui and nuklear do.
So, GL ES could be easily swapped between 2 and 3, also Vulkan could be added later.

I hope there is no too much code relying on GL. Will track this issue to know fyne better :)

[andydotxyz]

After this is done we will create a mobile driver. Yes it will need to share a rendering backend with the desktop driver (currently called “gl”) to some extend. Unlike other packages we try to hide the driver details behind the app constructor so we have some flexibility to change things around as this evolves. My expectation is that we will split the gl driver into 2 portions - the true “gl” will remain here but the glfw desktop stuff will be split out (maybe move to “desktop”?)

[Bluebugs]

Moving to GL ES seems very straight forward... Kind of :-) Basically just the shader really need change, and it is just a few macros to add. The main issue is the code needed to switch between all the different "architecture"/"target" that kind of lead me to think now that we might want to just jump to goxjs/gl directly. Otherwise we have to add the support for GL ES and GL in parallel as many desktop do not have GL ES. While jumping to goxjs/gl directly solve the portability issue (by directly give us mobile and web support) and limit the support for GL ES to just be a change in the shader. Basically making it one backend to rules them all (And all the portability complexity is moved to goxjs/gl).

This would make #183 irrelevant. I will try to spend some time on this next Tuesday and see where we stand after enabling a webgl/gopherjs of Fyne.

[andydotxyz]

Whilst we could have two different OpenGL implementations in the backend it would potentially mean that #129 would not be able to expose a single API for a cross-platform GL canvas object

[Bluebugs]

Hum, Indeed. I didn't think about that, but maybe a solution for #129 would be to expose a context from goxjs/gl and let that abstraction help us. It would enable an API that is the same on all target, only the shader will need some tweaking for with a bunch of #ifdef .

[andydotxyz]

I would really like to avoid the need for developers to ifdef their code if run through Fyne.
I am not sure what the right solution is here I must admit. I will move #129 out to the 1.2 milestone so perhaps we can solve it internally first then figure out how to expose to other developers once it's stable internally.

[Bluebugs]

The ifdef is inside the string of the shader. I don't see a way to take care of that for the user. Will think about it.

[andydotxyz]

This has slipped to the next release :(

[andydotxyz]

This is now working on the develop branch.
It will be included in 1.2 but the release is not yet scheduled.