You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[image] Provide some way to read and use image headers before deciding whether to fully decode the image #50022
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.
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.
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.
Activity
dnfield commentedon Feb 3, 2020
Context: #48305
dnfield commentedon Mar 4, 2020
Created a design doc for this at https://flutter.dev/go/encoded-image-dimensions
chinmaygarde commentedon Jun 15, 2020
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.
dnfield commentedon Jun 15, 2020
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.
dnfield commentedon Jun 16, 2020
Dropping the engine tag - instead pursuing #59578 to clean up some of the engine API around instantiateImageCodec.
dnfield commentedon Sep 24, 2020
This is actually basically done with the ImageDescriptor API in the engine, but none of it is exposed in the framework yet.
zanderso commentedon Nov 13, 2020
@dnfield #59578 implies that this issue may be obsolete. Can this be closed? Is there still some framework change to do?
dnfield commentedon Nov 13, 2020
Yes, this isn't wired up through the framework yet.