Android backend

[MarijnS95]

Fixes #44

Contains my hacks to further discussing Android support. There are two issues:

• Format is RGBA or RGBX;
• Buffers almost always have a stride() != width(), requiring us to deal with that (and IOSurface on Mac seems to have the same?).

These could either be solved by exposing this information to the user (more work and documentation for them, but also more performant) or kept hidden by maintaining the current API, but requiring an extra framebuffer allocation that we convert when they submit the frame.

[ids1024]

These could either be solved by exposing this information to the user (more work and documentation for them, but also more performant) or kept hidden by maintaining the current API, but requiring an extra framebuffer allocation that we convert when they submit the frame.

Currently the web backend converts to RGBA on present. We can do the same here, if we want to merge this before we figure out #98.

Ultimately we'll want that to provide an API that lets a client enumerate supported formats (some backends may support only BGRA, only RGBA, or both, etc.). And either use a native format or provide an easy way to convert when needed.

[ids1024]

Adding a stride() is unnecessary for now, if it converts on present anyway. But we'll need that for this for IOSurface, or anything else where we write directly into memory in a format the GPU may handle with a stride requirement.

So that can be added to the API when #98 is implemented.

[ids1024]

We have a mention of how to run the example on webassembly in the readme: https://github.com/rust-windowing/softbuffer/#webassembly.

So a quick mention of Android there would be good.

[MarijnS95]

These could either be solved by exposing this information to the user (more work and documentation for them, but also more performant) or kept hidden by maintaining the current API, but requiring an extra framebuffer allocation that we convert when they submit the frame.

Currently the web backend converts to RGBA on present. We can do the same here, if we want to merge this before we figure out #98.

No fuss/hurry to get this merged before fleshing out the details.

Ultimately we'll want that to provide an API that lets a client enumerate supported formats (some backends may support only BGRA, only RGBA, or both, etc.). And either use a native format or provide an easy way to convert when needed.

Sounds like a plan.

Adding a stride() is unnecessary for now, if it converts on present anyway. But we'll need that for this for IOSurface, or anything else where we write directly into memory in a format the GPU may handle with a stride requirement.

It's necessary unless we code in the conversion on present. And Android might again do a conversion after that.