Various notes/thoughts about the 2D vector graphics renderer

Triangle Rasterization
----------------------
https://fgiesen.wordpress.com/2013/02/08/triangle-rasterization-in-practice/

https://github.com/rygorous/trirast/blob/master/main.cpp

https://joshbeam.com/articles/triangle_rasterization/

https://nlguillemot.wordpress.com/2016/07/10/rasterizer-notes/

https://web.archive.org/web/20120625103536/http://devmaster.net/forums/topic/1145-advanced-rasterization/

Bindless textures
-----------------
It's tempting to use bindless textures to be able to draw individual images using only one draw call. This would avoid much of the complexity of either managing a texture atlas under the hood or breaking the draw list into batches...
But, it's only an extension and seem to not be supported everywhere. Moreover, there might be a problem where the texture handle used by the shader can not differ between batches (must be "dynamic uniforms"), which defeats the purpose in our case -> it requires OES_gpu_shader5 or GLES 3.2

ideally, the atlas should be built on top of lower level image features of the renderer, eg mg_image_upload_sub_region(), mg_image_render_sub_region() etc...

This would mean individual textures can be set and used in a frame. So without bindless textures, we would need to break down the draw list in batches, each time the texture attribute changes. This also mean we need to blend each batch result to the previous one.

 - It seems possible to implement bindless texture in metal using argument buffers
 - We could investigate if angle/our targets likely support OES_gpu_shader5
 - But, this means the canvas renderer relies on the backend to provide this kind of feature
 - It also assume the upper bound for indexable bindless textures is enough on every backend
 - We'll likely need a batching fallback anyway?


-> Angle doesn't seem to support GL_IMG_bindless_textures for now.

Workaround: we could use a desktop GL 4.3+ context for the canvas renderer on windows, _BUT_ the functions would conflict with the GLES canvas. Except if we use function pointers that are loaded differently for each context (which we probably should but I'd better keep it for later).

-> We'll probably want to do that, or make 1 draw call per changing texture.

Anyway for now, is it possible have an _under the hood_ atlas, and reserve a way to change the API so that we make the atlas explicit / allow using single textures for big images etc?

* We could decide that we can set an atlas, and all mg_images get allocated from that atlas. If no atlas is set a default one is used.

* or, we can expose mg_texture and related APIs for now, as if they were individual, but back them by a hidden atlas. And a bit later expose mg_image/atlas -> maybe better.

* Or just implement breaking the triangle stream into batches now...