Tighten up Stage contexts vs layers naming

[TodePond]

It's inconsistent what a layer is and what a context is, including in the docs.

Also it's weird to pass through magic words that I've invented, alongside magic words that are real. But maybe that's fine? What made me think of it: How would I add an "imagedata" layer type?

And also, no way for users to add their own layer types easily.

[Magnogen]

Also, we might want to do 3d stuff like with WEBGL, or even some sort of glsl shader. I'd suggest those two types of layers too.

If you're adding pixeldata as something seperate to a 2d canvas, could it be worth just making the context include the necessary methods and properties? That way if someone wants to do either one, they can be sure they're getting the things they want.

Could also allow custom contexts such as:

• 2d (the default context we all know and love)
• shapes (only allows circles, rects, lines, colours, etc. Could also add some nice sugar like a star or an equation like (`x**2 + y**2 <= ${r}**2`))
• shader (something like I mentioned earlier - perhaps with a glsl polygon that has a shader attached to it, and then there could be methods to allow changing the shader code, or passing in parameters to it)
• maybe some more?

[TodePond]

So I'll at least add the "webgl2" context from the browser API. We don't need to invent a name for that one: https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/getContext

I think there's potential for making a p5-like API like you describe with shapes. I think I'd probably add them as extra functions on top of everything though, to not complicate things.

The main reason I mention an image data context is that it feels like a common enough piece of boilerplate related to the render loop. ie: putImageData in tick, and initialising the imageData in start, and resizing it during resizes. This is really the job of stage so it would be good to have a layer type for it.

[TodePond]

Oh I do have plans for svg layers #61 and webgl layers #16

[Magnogen]

SVG definitely sounds like a good idea. And it makes sense to allow glsl2, just like 2d.

As for a p5js-like api, it can definitely be good for making drawing more concise, but it can also make the library quite big. How simple do you want to keep things?

[TodePond]

So far I'm thinking

Name	Description
2d	2D Canvas Context
webgl2	WebGL2 Canvas Context
html	HTML Element
svg	SVG Element
image	Image Data Array

And then I'm thinking of doing something this in the long-term:

import { fillEllipse } from "./habitat-embed.js

fillEllipse(context, x, y, width, height)

For things that are often used but missing, eg: It's annoying to use the arc function to just draw a simple circle.

[TodePond]

Improved with 94dfdc151627aebf3a29b4332c3f3463093a9b1e

[Magnogen]

Nice! This looks like a fantastic addition