Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Infinite rendering object size and a way to know its actual native size #104

Closed
yjoo9317 opened this issue Jun 14, 2019 · 17 comments
Closed

Comments

@yjoo9317
Copy link

I've been playing and struggling with flare component for a while.

I am not sure how the size in artboard works.
I thought the size in artboard would matter since it has fit property along. But some how but it didn't seem it does.
So I am a bit confused how fit property in the actor actually works.
It seems like Flareactor is regarded as flexible widget without any dimension even though it knows the size of artboard.

  1. Is it true?

For example, if I put the flareactor in Fittebox, then it gets infinite size unless the FlareActor was contained in a container with BOTH width and height defined.
If I want to use flare's native size( i.e., artboard size) to go with less scaling process, then I have to build at least once to know its artboard size.
2) Is there a correct way to do that other than building once?

@luigi-rosso
Copy link
Contributor

luigi-rosso commented Jun 14, 2019

Hi @yjoo9317,

The FlareActor widget doesn't have any intrinsic size of its own (although we could look into adding that as an option). The fit property is used in combination with the dimensions of the space allotted to the FlareActor. Right now the FlareActor does need to be inside of a sized widget.

So 1. is true, 2. we don't currently provide the intrinsic size but we could modify the FlareActor to do this and/or determine this from a property like useIntrinsicSize or something.

Some examples of how Fit will work:

  • Assume your Artboard is 100x100.
  • You place your FlareActor in a Container with size 200x200.
  • BoxFit.contain will scale Artboard and its contents up 2x, to 200x200.
  • BoxFit.cover, fill, fitHeight, fitWidth will do the same thing since the aspect ratio is the same.
  • BoxFit.none will keep the Artboard at 100x100, regardless of the size of the containing widget.

Another example:

  • Assume your Artboard is 100x50.
  • You place your FlareActor in a Container with size 200x200.
  • BoxFit.contain will scale Artboard to 200x100, and the letterboxing/empty space will be distributed depending on what you provide as the alignment.
  • BoxFit.cover will scale the Artboard to 400x200, and the width will bleed and be clipped out of the edges of the container, again the alignment will determine whether it's centered/left aligned/etc.
    ...and so on

@yjoo9317
Copy link
Author

Hi @luigi-rosso
Thanks for the quick response.

So then,
when we have a set of animated icons ranging from small to extra large and if I want to contain them in the right sized container (since flare needs to be in a sized container), then there is no exact way to do that unless we use predefined size constants for those cases.
Since I want to create the flareactor as defined in the artboard, and put it into any layouts.

@luigi-rosso
Copy link
Contributor

Right now, yes. But we've been thinking of a few different things to help with this. One of them is allowing the artboard size to be used as the intrinsic size of the FlareActor which means you won't have to specify a container, and the other is to allow you to specify the artboard (by name) to use if you have a file with multiple artboards.

@yjoo9317
Copy link
Author

I don't want it to be Q&A session.
But I want to ask you the following. Sorry for that and thank you.
The artboard size can be obtained only after building up the flare actor at least once right?

  1. or Is there any way to know the artboard size beforehand so we can use the size during the build?
    Right now, I just let it go through build once after that, get the size and set state.

  2. Is there any benefit from managing the flare controllers. Like create a controller for an animation, and keep it and re-use whenever needed.
    If there is not much, then we can just create the flare actor without specifying the controller.

@luigi-rosso
Copy link
Contributor

No problem, this kind of feedback is really helpful for us. We know we still have a long way to go with improving our documentation/tutorials/etc, and this helps us know what to focus on.

  1. The size of the artboard is known as soon as the Flare file is read in. If you take a peak at the lower level flare_dart package you'll see that at the highest level you have an Actor. This is a representation of your file, it contains all the artboards, assets, etc. Right now we only let you query for a single artboard. So you can do, actor.artboard to get the artboard. From there you can query the width/height via artboard.width/height or artboard.artboardAABB to get the world space bounds.
  2. Usually you only use a custom controller if you want very specific functionality (like mixing multiple animations concurrently). There's no inherent performance/efficiency benefit.

One other thing I realized, you can actually specify the name of a node to be used in place of the artboard bounds. For example, you could make a rectangle and call it "SizeRectangle". Then you can supply the name "SizeRectangle" to the FlareActor via the boundsNode property. This is helpful if you want to change the area that gets aligned by the fit/alignment properties.

@yjoo9317
Copy link
Author

yjoo9317 commented Jun 14, 2019

another dumb questions.

  1. How exactly I can get an Actor? I couldn't find interface.
  2. Since I don't know the answer for Adjusting the runtimes for the new readable format. #1, Is it separate path beside building FlareActor ?
  3. For flare controller,
    I noticed that if I reuse the controller, when we show one animation and have same animation on next page as well, then the animation on the next page shows the last moment of the animation briefly and starts from the beginning. I am resetting the controller like below while disposing the current widget using the controller _flareAnimation.time = 0.0; _flareAnimation.apply(_artboard); but still it didn't work or did work but not quick enough.

@luigi-rosso
Copy link
Contributor

  1. & 2. Take a look here:
    Future<FlutterActor> loadFlare(String filename) async {

This loads a Flare file from an asset bundle. The important lines are the ones below:

FlareCacheAsset asset = await cachedActor(assetBundle, filename);
// now you can use asset.actor
  1. That's weird, it should be instantaneous unless for some reason the apply is happening after an advance. Try calling _artboard.advance(0); right after your apply and see if that helps. If that does it then something is getting processed out of order somehow...

@yjoo9317
Copy link
Author

yjoo9317 commented Jun 17, 2019

Thanks @luigi-rosso
I tried to use FlareCacheAsset to use the actor's artboard and it worked.

One question though, underlying cachedActor is async which is a bit tricky to use in build().
Because of that It still needs to run build twice at least.
The first run for getting artboard and the second run for building the flare with size, like the below.
Is there any way to do it one path?

  Widget build(BuildContext context) {
    FlareActor actor = FlareActor(
      flareFile,
      alignment: Alignment.center,
      fit: BoxFit.none,
      controller: this,
    );

    if (_artboard == null) {
      cachedActor(
          DefaultAssetBundle.of(context), fileFile)
          .then((cacheAsset) {
        onArtboardReady(cacheAsset.actor.artboard);//artboard obtained.
      });
      return Container(width: 1.0, height: 1.0);
    }
    else {
      Widget flare = Container(
        child: actor,
        width: _artboard.width,
        height: _artboard.height,
      );
      }
      return flare;
    }
  }

@yjoo9317
Copy link
Author

Thanks for the help.

@luigi-rosso
Copy link
Contributor

I’ll take a look at you’re other question soon! Sorry I haven’t been able to look yet.

@luigi-rosso
Copy link
Contributor

There might be an opportunity to report back the read size earlier, but it would still likely be async as we try to push the heavy read operation to a separate isolate. It's similar to reading an image, you won't know the size until you've loaded it.

Let me see if there's a way to change FlareActor to use its own intrinsic size.

@luigi-rosso
Copy link
Contributor

@yjoo9317, give this a try:
https://github.com/2d-inc/Flare-Flutter/tree/intrinsic_size_experiment

Point your flare_flutter to the branch intrinsic_size_experiment in your pubspec:

flare_flutter:
  git: 
    url: git://github.com/2d-inc/Flare-Flutter.git
    ref: intrinsic_size_experiment
    path: flare_flutter

Then simply tell your FlareActor to use the artboard size:

FlareActor actor = FlareActor(
      flareFile,
      sizeFromArtboard: true
    );

@yjoo9317
Copy link
Author

Wow.. will try soon. Thanks.

@yjoo9317
Copy link
Author

yjoo9317 commented Jun 21, 2019

Looks like I am having a path issue here. Rings any bell? From the other branch, it is just flare_dart though. Not with ../ Please let me know if I am missing something before building it.

Error on line 12, column 11: Invalid description in the "flare_flutter" pubspec 
on the "flare_dart" dependency: "../flare_dart" is a relative path, 
but this isn't a local pubspec.
   ╷
12 │     path: ../flare_dart

@luigi-rosso
Copy link
Contributor

Oh yeah let me fix that up...

@luigi-rosso
Copy link
Contributor

Ok try changing the pubspec to this now:

flare_flutter:
  git: 
    url: git://github.com/2d-inc/Flare-Flutter.git
    ref: 29d550940c2693f2fe0f9167c5070694e76f6b87
    path: flare_flutter

That goes to the latest tree in intrinsic_size_experiment which now points to the repo instead of using a relative path.

@yjoo9317
Copy link
Author

@luigi-rosso
It works great!! I really appreciate it. 👍
When it will be going down to dev branch?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants