Fabric.js: 2.0 rc checklist

Created on 27 May 2017  路  41Comments  路  Source: fabricjs/fabric.js

  • [x] take the intro part 1 to part 4, update

    • [x] part 1, update

    • [x] part 2, update

    • [x] part 3, update

    • [x] part 4, update

  • [ ] read all the old and new text method, check if something is missing and add them

    • [x] take care of #3929

  • [x] close the issue tagged as 2.0 milestone
  • [x] merge new filter code
  • [x] prepare examples for new filter code and explanation of what is new

    • [x] take care of #3967

  • [x] remove pathgroup completely
  • [x] remove current alignX, alignY, meetOrSlice from images from SVG, propose alternative.
  • [x] investigate textbox scale handling and do something.
  • [ ] Add tutorial for pan and zoom
  • [ ] Update demos that do not show new properties

    • [X] controls demo updated

    • [X] Free drawing demo updated

  • [x] Make sure website is not using named setter/getters
  • [x] I think we have an issue with path.sourcePath
  • [x] Check why text pattern fails
  • [x] Check svgimport and origins different from top/left

I have not a date yet, and i cannot make a broken release.

All 41 comments

Will Fabric 2.0 allow us to create Text item that can scale and resize? Like in shutterstock editor :-)

good point. another thing i wanted to fix was the broken textbox. i did not have chance yet.
As of now textbox cannot handle scale different from 1. i guess if that changed with refactor of text i did.

How about Node-canvas 2.0 support? (if it reaches a stable release before you release 2.0)

my node canvas knowledge is low.
i would need a set f js tests to run with confidence.
There is no problem in updating later as soon as is ready since fabric is switching to node 4+ and this should be ok for node canvas 2.

Also regarding pango lib, fabric already needs that or custom fonts work bad

I understand and respect the decision to wait. There is no hurry on my side since I'm currently able to render fonts on the client, and what you're working on now is more important anyway :)

Regarding Pango, it's more accurate than Cairo for font rendering in itself, but the node-canvas implementation for loading custom fonts with Pango was broken before 2.0, in effect making it necessary to add custom fonts to the system (I haven't tried this, only read it) or remove Pango and rebuild node-canvas so it will fallback on Cairo (less accurate).

keeping docs updated is the most overwhelming and boring task

Could you consider adding a check on performance regression ? Testing v2-beta3 and seems very slower than v1

that is completely unexpected. on what scenarios?

With some elements in cache. The real issue is that you really do not have to have a lot of elements to make your browser crash because of the cache. See

http://jsfiddle.net/S9sLu/1824/ v2.0.0
https://jsfiddle.net/y12yLvgv/26/ v1.7.7

On the jsfiddle using v2 loc 6 you can toggle the cache, when activated it is very laggy. When activated and having hundreds of elements instead of tens, it just crashes.

gonna check it asap

http://jsfiddle.net/S9sLu/1825/
https://jsfiddle.net/y12yLvgv/29/

The real perf killer is the shadow.
With caching and groups and shadow you get an hit.
You get less hit if you assign shadow to the group and not to the rect ( with caching enabled )
For me with 600 objects is smooth with shadow disabled.

For browser crashing you mean browser asking you to kill or wait?

Ok, but why so much perf differences between v1 and v2 ?

Chrome tab crashing with the dead face.

Here another example with all our default settings http://jsfiddle.net/S9sLu/1826/
Adding or removing shadow has minor impact, the real perf killer is caching.

try to move some rect:

  • no cache, no shadow: feeling = woot woot, 20fps
  • cache, no shadow: feeling = bouncing, 30fps

fps number does not reflect the feeling I have moving rectangles around. Adding cache increase fps from 20 to 30 but the feeling is really sharp without cache, while really bouncing and laggy alike with cache which add an odd feeling.

  • no cache, shadow: feeling = woot, 15fps
  • cache, shadow: feeling = very laggy, 2fps

Here adding shadow decrease performances, but to the eye it is still very acceptable, even more acceptable than the bouncy 30fps from above (cache-noshadow)!! Then the fps killer... cache + shadow = bouncy + laggy together.

  1. I do not know what happens with shadow when using cache, but that's very odd it kills fps this much
  2. Memory raises fast when using cache and do not seems to decrease. Warning on memory leak. I would advice using weakmap or finite typed array to store object refs when available, reusing same canvas object to pre-render, cache & pre-render group together instead of one by one.

so the shadow rotates with angle, internally a shadow with an offset stop the group from caching in the same canvas.
This means that Group with shadowed rect and text, will create a normal group that has internally 2 cached object. The worst condition ever.

If you disable shadow or give it 0 offset ( just blur ) the caching is possible. So one group one cache.

This is the main reason of slowing down to 2 fps

The memory does not decrease beacause the cache canvases are in use, and they are kept unless you remove some object. Teorically the objects that are completely out of screen should not get theyr own cache populated since the render is skipped.

You should have caching canvases, as big as 256x256 or more, one per object or one per group.

no cache, no shadow: feeling = woot woot, 20fps
cache, no shadow: feeling = bouncing, 30fps

if is bouncing that means that some GC is happening while rendering, that should not happen

In this fiddle skipOffscreen is not working because the canvas is 1920x1080 and all the objects are on screen. ok that is fine.

Other than that there are no difference between 1.x and v2 branch. All the rendering functions are backported to 1.x even if developed on 2.0.

I will try to have numbers with v1 asap to see if the feeling I had is real, and post some profiling graph.

sorry @asturur but there is definitely a regression, with v1 I got

  • no cache, shadow: feeling = little laggy, 10fps (v2 is 15fps)
  • cache, shadow: feeling = woot, woot, 30fps except 1fps rarely, not perceptible at the eye (v2 is 2fps constant) and memory is not raising this much.
  • cache, no shadow: feeling = woot, woot, 30fps, 40fps sometimes, no boucing effect at all

Maybe you have more RAM than me, you might want to throttle memory and cpu or add more rectangle to see the same issue.

So there is a problem in v2 with cache and shadow. but if you move the shadow at group level instead of rect level, it should behave as v1

nope, those stats are with shadow on group level already

I have a co-worker with a macbook retina (I'm on PC with Ubuntu) he has to go with 1000 rectangles to get near the same feelings & fps numbers

Ok so the v2 at 2fps must be invetigated.
Can you record a profile at 2fps of a couple of seconds drag?

fabric-v2-cache-shadow-2fps

I have a lot of cpu other tasks and few cpu scripting tasks compared to best case (without shadow without cage) Could that be the garbage collector ?

i do not understand how do you get 4800 nodes without cache.
To see if the garbage collector kicks in ( and it looks like since the memory is doing up and down ) zoom on the graph where is the grey activity and you can find the labels that says minor GC major GC

fabric-v2-cache-shadow-2fps-gc_before
This one is cleaner, I forced GC just before. But above use case can happen if a user come & go on a canvas (that's what I did)
Still 2fps
I get 1200 nodes which match 600x2 => rect + text ?

i do not understand how do you get 4800 nodes without cache.

This is with cache. Cache & shadow.

did moving the min cache size to 64 improve something regard memory usage?

Yes if shadow is inside the group, and offsetX or offsetY are different than 0, the group is not cacheable ( unless you do not rotate, but fabric does not know that ) you get a cache for each element. 600x2.

the best way you could get out of it, fast is create a custom container class, with 0 dimensions, that has the ability to cache whatever you are not moving.

On mouseDown you will decide if that cache needs a refresh, and you need to insert code in fabric in some points to make it work. At least this would be an effective solution.

Also i noticed you work with a 1920x1080 setup. if you are working to cover a full screen that is ok, if you are using a bigger canvas to get a scrollable element, this is sub optimal.

I updated the website to run on the beta. This helps a lot in finding out regressions, and helps me working on a demo/tutorial at time.

Can you tell us a bit more about ActiveSelection? I can't find information in the updated intro parts.

Thanks!

I have to still write it. :(
Maybe this evening, since is still fresh for me, it will help to get problems out before release.

The basic idea is that the multi selection code, has been removed from group that now is just a container.

The activeSelection class (new fabric.ActiveSelection([obj, obj, obj], options) ) is a group, that auto destroy on deselect and has the code to behave as multiselection.

There are default methods to transform a group in a selection and a selection in a static group, since many people want to do that ( a sort of group/ungroup official code)

I know it's not exactly the place to talk about this, but I tried to use active selection: https://jsfiddle.net/v4h0f7gh/5/
or https://jsfiddle.net/v4h0f7gh/6/
but it doesn't seems to work as I except. Do I need to add the activeSelection to the canvas?

https://jsfiddle.net/v4h0f7gh/7/ there was a double link to fabric, maybe that is way was not working.
Your code is right and looks like working now.

Great, thank you!

It seems there is a bug with the canvas zoomed & active selection:
https://jsfiddle.net/v4h0f7gh/8/
Or maybe I need to pass some options?
I can create a new issue if you want it easier to follow.

the activeSelection needs a reference to canvas { canvas: canvas } in the options.
But i think from an api point of view, that can be done from setActiveObject.

Example updated as you told me and it's now perfect, canvas zoomed and active selection:
https://jsfiddle.net/v4h0f7gh/9/

After adding the new logic on activeSelection and group into our app, I wanted to thank you. The new system is perfect. You'll have riots but riots of love! 鉂わ笍 馃槃

There seems to have a strange behaviors in the group/ungroup new function.

If i do a activeObject.toGroup() it work and create a group, if i follow with a .toActiveSelection() it work and it do an ungroup with a selection of the objects.
But if i do a new .toGroup() the objects are deleted. Are you sure there is not some lost informations when there is multiple group/ungroup ? Should i open a jsfiddle ?

http://fabricjs.com/v2-breaking-changes

Started a series of explanations of what is new.

For who is interested i m writing bit a bit some documentation that you find browsing on fabricjs.com starting from the changelog link.

closing this one.

Was this page helpful?
0 / 5 - 0 ratings