Support compositingMode in Bloc-Alexandrie (WIP)

[tinchodias]

It may be too simplistic support, I should check non-trivial examples.

Basically, when an element has to draw itself on a canvas and responds true to wantsSeparateCompositingLayer, then it's cached in a Cairo surface that, if didn't change, will be reused on next space redraw.

There are three options:

• anElement beInSingleCompositionLayer, that caches itself and all recursive children in a single surface (it doesn't matter if any of the children have one of these options)
• anElement beInSeparateCompositionLayer, that is similar to previous option but any children can be cached separately.
• The element has an effect that answers true to wantsCompositionLayer. This is the case for BlGaussianShadowEffect.

[labordep]

Thanks @tinchodias, I don't understand wantsCompositionLayer option ?

[tinchodias]

hi @labordep that's the testing method that the element uses to check if it will cachecin a surface. Any of the 3 options I enumerated makes the testing method answer true

[labordep]

Ok thanks :-)

[ELePors]

Just a comment about that, We noticed also a slow down when using some effects, i think that the buffering is not efficient.
I just tried to build a form using exportAsForm to have a buffer of my BlElements, i hide my blElement composition and i show the buffer in a new blElement... and i dragged it... and it was fluid...

But when i use '''beInSingleCompositionLayer''' it is still slow...

I think there is a lot of computations when moving a BlElement container, even if it is buffered...
not simple :)

[ELePors]

And i think that a Form is NOT the solution for buffering, It have to be a primitive element from the Canvas, an efficient buffer manipulated by the native canvas and cached by the BlElement as an external ressource pushed to the canvas at will to avoid redrawing... (like a CairoTexture ? )

[tinchodias]

Hi @ELePors !

I think there is a lot of computations when moving a BlElement container, even if it is buffered...
not simple :)

this can be key

But (assuming you have loaded the PR #268)... Some points that come to my mind, I hope any of them help:

1. We can see the current state of layers by inspecting:

(space root allChildrenBreadthFirstSelect: [ :each |
	each hasCompositionLayer ]) collect: [ :each |
	each compositionLayer surface ].

2. The layer both generated and applied in BlElement>>#ensureLayerAndDrawOn:. It's a place to insert "debug code" to watch what happens. Maybe a layer is generated too many times more than needed.

3. The AeCairoImageSurface generated there is an external resource as I understand it, it leaves outside Pharo in C structs of cairo library... but yes in regular memory, not in videocard memory, I think you refer to this... a SDL_Texture would be cool. I will do a new attempt to implement it fast (before I tried but failed).

4. Also, as a closer alternative we can try generating a new Cairo group instead of a new Cairo surface. This would be sending AeCairoContext>>#pushGroup and AeCairoContext>>#popGroupAsSurfacePattern.

[ELePors]

And if the BlElement is buffered and not dirty, when we change his position, it shoud not alter subElements... or we should have a way to move it without recomputing, and afrer move is finished, force computation... if you see what i mean ?

(i am on dev-1.0 and up to date)

[tinchodias]

(i am on dev-1.0 and up to date)

Ah but this PR is the only that makes layers work

[ELePors]

i just checked out the alexandrie_composition_layer branch ? Is it that ?
I have a composite BlElement named "CWMap" what do i have to do ?

[tinchodias]

When an element changes, will BlElement>>#markNeedsPaintFrom: marks it (flags addNeedsPaint) to regenerate the layer. When an element with layer already generated moves, what's marked is the parent of it.
This is what I understand at the moment.

[tinchodias]

@ELePors you can send the beInSingleCompositionLayer to the CWMap

[ELePors]

Ok (i am on discord if you prefer)

[tinchodias]

Failing tests are not produced by this PR