Verified
Status Update
Comments
il...@google.com <il...@google.com> #2
We have shared this with our product and engineering team and will update this issue with more information as it becomes available.
ga...@google.com <ga...@google.com> #3
How fast would it be compared to JPG/PNG, for encoding/decoding?
ap...@google.com <ap...@google.com> #4
Encoding: depends on encode effort, but generally speaking faster than PNG, a bit slower than JPEG.
Decoding: a bit slower than PNG and JPEG (unless you use multithreading, then it can be faster).
Both encode and decode should be fast enough for most use cases on current phone cpus.
Decoding: a bit slower than PNG and JPEG (unless you use multithreading, then it can be faster).
Both encode and decode should be fast enough for most use cases on current phone cpus.
ap...@google.com <ap...@google.com> #5
@4 Interesting.
Thanks.
Thanks.
ap...@google.com <ap...@google.com> #6
For both opening in Webview and as a saved filetype with third party editors
jb...@google.com <jb...@google.com> #7
Would love to see this backported to older versions of Android/PXL phones too!
gr...@google.com <gr...@google.com> #8
Can't wait to have JXL supported on Android and being the new default. So much potential to push photography forward with features such as HDR, depth maps and better quality in a smaller size. Such exciting times to come.
Description
Component used: activity-compose -
PredictiveBackHandler
Right now, when getting the progress events, you can tell the
touchX
andtouchY
and the progress, but you’d need to manually track the velocity to understand the velocity with which a gesture is performed.I’d like this velocity to be able to use
animateDecay
, oranimateTo()
onAnimatable
, to be able to smoothly finish the animation from where it left off. To do this, I’ve addedVelocityTracker
, but the BackEvent doesn’t containuptimeMillis
, leading me to useSystem.currentTimeMillis
, which could be inaccurate if an event comes in a different order.