Skip to content

[image] Provide some way to read and use image headers before deciding whether to fully decode the image #50022

Open

Description

@dnfield

I suspect the right way to do this would be in Dart code, somewhat the way package:image does it, rather than round tripping to the engine. However, if Skia has really nice routines for this and we know we want to shunt the data over to the engine anyway, that may make more sense - as long as the data can be reused for an actual decode.

/cc @alml

/cc @gaaclarke

Activity

  1. added
    frameworkflutter/packages/flutter repository. See also f: labels.
    engineflutter/engine related. See also e: labels.
    a: imagesLoading, displaying, rendering images
    on Feb 3, 2020
  2. dnfield commented on Feb 3, 2020

    @dnfield
    ContributorAuthor

    Context: #48305

  3. added this to the milestone on Feb 11, 2020
  4. dnfield commented on Mar 4, 2020

    @dnfield
    ContributorAuthor
  5. added
    c: performanceRelates to speed or footprint issues (see "perf:" labels)
    on Mar 30, 2020
  6. added
    P2Important issues not at the top of the work list
    on May 29, 2020
  7. chinmaygarde commented on Jun 15, 2020

    @chinmaygarde
    Contributor

    This is trivial to expose from the engine but your proposal seemed to indicate a desire to calculate this information from Dart code itself (possible in a package). Is this still the case? If so, let's remove the engine tag.

  8. dnfield commented on Jun 15, 2020

    @dnfield
    ContributorAuthor

    The proposal was for a way to do this from Dart code - it's not implemented yet though, and in theory could be done engine side.

    I was looking into this more in the last few days, and it looks like we actually do some aspect ratio maintenance but it's poorly documented. I'm starting to think this should be an engine change rather than what I was exploring in the proposal - something to make the aspect ratio logic a bit clearer.

  9. added
    would be a good packageSeparate Flutter package should be made for this
    and removed
    engineflutter/engine related. See also e: labels.
    on Jun 16, 2020
  10. dnfield commented on Jun 16, 2020

    @dnfield
    ContributorAuthor

    Dropping the engine tag - instead pursuing #59578 to clean up some of the engine API around instantiateImageCodec.

  11. removed this from the milestone on Aug 17, 2020
  12. dnfield commented on Sep 24, 2020

    @dnfield
    ContributorAuthor

    This is actually basically done with the ImageDescriptor API in the engine, but none of it is exposed in the framework yet.

  13. zanderso commented on Nov 13, 2020

    @zanderso
    Member

    @dnfield #59578 implies that this issue may be obsolete. Can this be closed? Is there still some framework change to do?

  14. dnfield commented on Nov 13, 2020

    @dnfield
    ContributorAuthor

    Yes, this isn't wired up through the framework yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Important issues not at the top of the work lista: imagesLoading, displaying, rendering imagesc: performanceRelates to speed or footprint issues (see "perf:" labels)frameworkflutter/packages/flutter repository. See also f: labels.perf: memoryPerformance issues related to memoryteam-frameworkOwned by Framework teamtriaged-frameworkTriaged by Framework teamwould be a good packageSeparate Flutter package should be made for this

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions