feat(BaseBrush): clipPath

[ShaMan123]

Overview

This PR adds a clipPath property to all brushes, aligning them with fabric.Object.
It BREAKS SprayBrush, it can be avoided with different naming if necessary.

Motivation

closes #7134
closes #6955
closes #5431

Demo

https://codesandbox.io/s/upbeat-microservice-mkbzs?file=/src/App.tsx

Logic

• Added a clipPath property to BaseBrush and exposed clip path methods
• Exposed a common render + _render method on BaseBrush which conforms to Object#render and is in charge of:
  1. Preparing the context (transformation etc.)
  2. calling _render which is implemented by each brush
  3. render clipPath
  4. cleanup
• Made all subclasses use _render instead of _render - BREAKING SprayBrush to make it compatible with all brushes (renamed it's previous render method to renderChunck), renamed EraserBrush render method to renderAll
• Added clip path support to segment rendering
• Added logic to apply the clip path to the resulting object created by the brush

To Do

• Eraser clip path - once feat(EraserBrush): V2 #7470 is merged can probably be supported by clipping the mask created by eraser brush

Watch

Pay no attention to eraser bug. It's fixed by the group PRs.

With Eraser patched up

absolutePositioned + viewportTransform

[asturur]

i do not think we should do that.
The brush should just respect the canvas clipPath if any, the issue is that rendering the topLayer, the contextTop is currently unmanaged, and brush, group selection, text selection, all fight for it.

We should work toward having a clear order of operation there and adding the clipPath there if necessary.

[ShaMan123]

Did you try the demo?
What about a use case that you need the draw over parts of the canvas. You can't achieve this right now. Say you want to draw only over some objects.
Ohh you mean that if I use active selection it will be clipped..... I get you. What if we render a cache canvas to workaround this issue?

[ShaMan123]

Thinking again it can't happen. Because once mouseup the brush clears the top context and creates a Path object meaning it won't collide with group/text selection.

[ShaMan123]

Isn't canvas clip path applied to all of it? That is not the use case described or the motivation of this PR

[ShaMan123]

I think this is a cool feature.
I'll put it at hold for now.

[asturur]

@ShaMan123 this is a cool feature, yes.
But i want to redo the contextTop or topLayer entirely.
This code will create a feature that will get in the way of reorganizaing.
In the top layer we need to be able to handle:

• controls
• group selection
• brush creation ( not always because for example the eraser brush needs to be in the main canvas )
• eventually small custom stuff for the developers

brush themselves need to be changed in something that is more similar to custom controls, one class and callbacks for your own rendering.

[ShaMan123]

@asturur what about this?
Want this in? I think it's great. Simply need to address the eraser and then the feature is supported by all brush interactions

[ShaMan123]

Updated from master.
Suitable for v6.
Eraser supported (needs group PRs to merge into master to function properly)
Something is off with Eraser. I don't know if it's eraser or the clip path.
Need to check deeper.

[ShaMan123]

Ready to merge!

[ShaMan123]

Fixed absolutePositioned
Build fails because of async usage.
Visual tests fail but after examining myself I don't see any visual difference.

[ShaMan123]

Updated from master, resolved conflicts and tested