OpenGL renderer and backend-agnostic graphics subcrate

[hecrj]

This PR implements an OpenGL renderer on top of glow, introduces a glutin shell, and abstracts a bunch of backend-agnostic rendering logic in a new graphics subcrate.

iced_glow

iced_glow is an OpenGL renderer powered by glow (GL on Whatever). This renderer is meant to be an alternative (not a replacement!) to iced_wgpu while wgpu and its ecosystem mature.

As iced_glow uses OpenGL, it should offer us better compatibility, stability, and maintainability for the time being. Furthermore, users that currently have OpenGL-based applications should be able to integrate them directly with iced.

On a related note, my work on this renderer also prompted me to write and open-source glow_glyph, a direct port of wgpu_glyph for glow.

Please, feel free to give the renderer a try by switching to the feature/glow-renderer branch and running any of the examples! Keep in mind that Image and Svg widgets are not supported yet.

iced_glutin

iced_glutin is a shell on top of glutin. It can be used to easily initialize OpenGL-based renderers, as it will create and properly configure an OpenGL context for them.

Given that glutin is built on top of winit itself, iced_winit and iced_glutin both share a good amount of logic. However, while iced_winit provides a raw-window-handle to initialize the chosen renderer, iced_glutin provides an OpenGL loader function instead.

The work on this crate also introduced a couple of new concepts in iced_native that should ease the integration of iced in existing projects (#313). Specifically, a Program trait has been added which can be used together with some program::State to feed events to a user interface and obtain its drawing primitives. The integration example has been updated accordingly to showcase how to use them!

iced_graphics

The first draft of iced_glow was implemented by copy-pasting a lot of code from iced_wgpu. As most of this code was backend-agnostic and shared between renderers, it was abstracted away and moved to an intermediate crate: iced_graphics.

iced_graphics contains a bunch of backend-agnostic types that can be leveraged to build a renderer. The most important concepts it contains are:

• The current Primitive type from iced_wgpu.
• A Layer type that flattens a Primitive tree for rendering.
• A default renderer that can be customized with a generic backend. It implements the Renderer trait for all the built-in widgets.
• Other useful types like Transformation, Viewport, a font loader on top of font-kit, etc.

And I think that's about it! I am aware there is a lot to unpack here. Once I finish writing the documentation for all the changes, I will share a link.

As always, any feedback appreciated and feel free to ask any questions!

---

• Fixes cargo run --package tour error (debian) #357
• Fixes White screen on tour example #350
• Fixes Crash when using more than one custom widgets that use Canvas features for rendering #349
• Fixes Canvas examples on MacOS don't work #342
• Fixes Error running example #284
• Fixes "cargo run --package tour" opens a window, but it’s invisible #257
• Fixes Panic running examples on Ubuntu 18.04 #212
• Fixes problem while running compiled app #194
• Fixes Examples fail on Macs without Metal support #182
• Fixes Crashes with assertion failed #148
• Fixes Another run example error: cargo run --example tour #98
• Fixes No Text, no Buttons #96
• Fixes Error when running examples: "extension NV-GLX missing on display" #72
• Fixes Winit Error when running Example on Ubuntu 19.04 #70

[Songtronix]

little copy paste accident I guess:
Application -> Program

Love your work!

[hecrj]

The new documentation is available at https://iced-docs.now.sh/iced/index.html

[Imberflur]

The iced_native top level docs still mention window::Backend which was moved

[hecrj]

I think this is ready to be merged!

The OpenGL renderer still does not support the Image and Svg widgets, but I believe we can tackle that in another PR. There are many foundational changes in this one and it's important we merge it so we can build on top of them.

Given that the OpenGL renderer isn't feature-complete yet, I have kept iced_wgpu as the default one. The iced_glow renderer can be toggled using the new glow feature flag.

[draivin]

Currently there is no way to create a glow renderer backend (as it is a pub(crate) export), is this intentional until things are more complete?

[hecrj]

@draivin Not intentional. I forgot about exposing it 😅

[hecrj]

@draivin I have exported it in 6cb9057.

[m4b]

Does this PR indicate that iced will slowly move away from using wgpu (and eventually not at all)?

[hecrj]

@m4b

No, as the description says:

This renderer is meant to be an alternative (not a replacement!) to iced_wgpu while wgpu and its ecosystem mature.

[m4b]

Gosh, sorry I missed that, thanks for clarification :)

[0x7CFE]

Are there any estimates on how hard it is to implement image support for OpenGL renderer? It's the only thing that prevents me from using iced on Raspberry Pi (see #428). With just a couple of shader hacks, everything else works fine.

[hecrj]

@0x7CFE It shouldn't be hard to get a similar implementation to the iced_wgpu one.

However, we should try to abstract and move the atlas logic to iced_graphics instead of duplicating code. Additionally, it would be great to set the foundations for asynchronous loading of images at the same time. This is the hard part.

[Tarnadas]

@hecrj is there a tracking issue for Image and Svg support for the glow feature?

Also, could it be that the current master fails to compile with the glow feature? I'm getting lots of errors.

[MCOfficer]

@hecrj is there a tracking issue for Image and Svg support for the glow feature?

Seconded. I would create an issue myself, but i feel like the OP of a tracking issue should contain all meaningful information, and it would be much better if you had control over that OP.