Layer proposal

[erickzanardo]

Description

With this we can do a lot of new stuff, like pre render background that don't change and etc.

I have also proposed here a processor api, to add cool effects to the entire Layer, have added a DropShadow processor to test.

This PR is still a proposal, I am want to discuss on top of it and see what you think.

Fixes #368

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

Checklist:

If something is unclear, please submit the PR anyways and ask about what you thought was unclear.

• This branch is based on develop
• This PR is targeted to merge into develop (not master)
• I have added an entry under [next] in CHANGELOG.md
• I have formatted my code with flutter format
• I have made corresponding changes to the documentation
• I have added examples for new features in doc/examples
• The continuous integration (CI) is passing

[mindplay-dk]

Looks promising!

Maybe some more descriptive layer naming? (tileLayer, spriteLayer, backgroundLayer?)

Is a background layer really required or might it be more efficient to save that layer and draw the background directly on the canvas?

[erickzanardo]

Maybe some more descriptive layer naming? (tileLayer, spriteLayer, backgroundLayer?)

You mean naming the variables?

Is a background layer really required or might it be more efficient to save that layer and draw the background directly on the canvas?

On this example there is no background layer, only a background color, but haven't a pre rendered layer seems like a good idea when needed

[spydon]

Cool stuff! Looks good to me.

[mindplay-dk]

You mean naming the variables?

Yeah, I just meant these - the names seem to describe how they're painted, not what you're intending to draw on them. Might make it a little easier to understand. Just being opinionated maybe - if you disagree with that, just ignore me. 😉

Anyhow, I'm finding the drawing logic not so easy to follow in some ways.

Here's a slightly different take: what if the layers were Components?

A layer would have an ordered set of components itself, like the Game has - and some of those components again might be nested layers.

The point is to get rid of this beginRendering/finishRendering hand-holding - instead you just create layers and add components to them.

This way, layer painting becomes a bit more "transactional", in the sense that you can't forget to begin or finish rendering every layer - and you can't mess up the order, like putting two begin-calls for a nested set of layers, and then putting two finish-calls in the wrong order; not even sure what would happen then, but that's probably not a meaningful operation? So it probably shouldn't be an option. Begin/finish could be just something that internally happens within logical layers, internally in the layer component instances.

That probably would make layer-based code a bit easier to read, and more safe to refactor - so like, you can set up your layers once, and then simply add components to them, easily move a component to a different layer, by just assigning it, without worrying about call order, etc.

Thoughts?

Also, maybe opacity and blend mode properties could be added? So we can use layers for things like brightening for explosions, darkening for smoke, etc. - and make layers that fade in/out. (one upside to having layer opacity, is you can bypass layer rendering entirely when opacity is zero.)

[erickzanardo]

A layer would have an ordered set of components itself, like the Game has - and some of those components again might be nested layers.

About the variable names, this example was just something for me to get started with the implementation. They really don't mean anything.

I don't think we should can't get rid altogether of the begin/end rendering, since we need to use the PictureRecorder class to get access to a in memory canvas, we kind need to mirror that. Also I think it is good to have it explicit that you are rendering on the layer now, as with this, we can have prerended layers, which would be really, really good backgrounds for example, where we can render it once, at the beginning, and them just render the layer on the canvas.

I am thinking on creating two additional classes, a PrerenderedLayer and a DynamicLayer. The first you would need render it upon creating, and the later it would be redraw every frame. That way we can kind of ofuscate te begin/end rendering.

We sure will have components for this, we just need to get the "plain" ready first.

[mindplay-dk]

I hadn't thought of pre-rendered layers, yeah - that's a valid concern.

It just seems like being able to begin and finish layer rendering independently isn't really meaningful? There are so many ways you can shoot yourself in the foot - calling begin or finish more than once, forgetting to call either, or making finish calls in the wrong order for nested begin calls.

Can we make the API safer somehow, without losing the flexibility? I had the same sort of "call symmetry" problem in a database API once, which supported nested transactions - I got around the issue by making the begin/finish methods private, and having a single public method, which would accept a callback, and this method would call begin, then your callback, then finish - enforcing the call symmetry, but preserving the ability to make nested transactions by calling the same public method from within your callback. The same might work here?

[erickzanardo]

I hadn't thought of pre-rendered layers, yeah - that's a valid concern.

It just seems like being able to begin and finish layer rendering independently isn't really meaningful? There are so many ways you can shoot yourself in the foot - calling begin or finish more than once, forgetting to call either, or making finish calls in the wrong order for nested begin calls.

Can we make the API safer somehow, without losing the flexibility? I had the same sort of "call symmetry" problem in a database API once, which supported nested transactions - I got around the issue by making the begin/finish methods private, and having a single public method, which would accept a callback, and this method would call begin, then your callback, then finish - enforcing the call symmetry, but preserving the ability to make nested transactions by calling the same public method from within your callback. The same might work here?

I am thinking on making the Layer class abstract, and provide to the final developer only the PreRenderedLayer and DynamicLayer, that way the "complexity" of the begin/end redering will be a internal thing.

[erickzanardo]

@luanpotter @spydon @mindplay-dk I have updated the base api, I think it is way better now, the begin/finish rendering are totally transparent now to the user, and you can still have the better of both worlds, take a look and let me know what you think.

Next I will try to add support to providing a Paint to the layer, so we can manipulate it, like we manipulate a common Sprite (opacity, color, and etc).

[erickzanardo]

I will leave a layer component for later, since that will require better planning, and this feature are already kind of ready to use, makes no sense to wait much to merge this.

[luanpotter]

LGTM, just a few comments (mostly trying to make the docs a bit more cleaner). also suggesting adding a new method to Layer.