Status Update
Comments
er...@google.com <er...@google.com>
br...@gmail.com <br...@gmail.com> #2
ChromiumPerf/mac-m2-pro-perf/blink_perf.css/NestingIdentInvalidValue/NestingIdentInvalidValue.html
Verification workflow id: projects/62121018386/locations/us-central1/workflows/sandwich-verification-workflow-prod/executions/a6b905ed-9343-4d2b-a994-55556a5aa8bd
hu...@google.com <hu...@google.com> #3
reproduced the regression with statistic: {'control_median': 13.009999999962748, 'lower': 10.344712166063431, 'p_value': 1.862645149230957e-09, 'treatment_median': 14.409999999776481, 'upper': 11.095673438085797}.
Proceed to bisection.
br...@gmail.com <br...@gmail.com> #4
Created by chromeperf@appspot.gserviceaccount.com
Benchmark: blink_perf.css
Story: NestingIdentInvalidValue.html
Measurement: NestingIdentInvalidValue
The job has been scheduled on the "mac-m2-pro-perf" queue which currently has
1 pending jobs.
hu...@google.com <hu...@google.com> #5
ChromiumPerf/mac-m2-pro-perf/blink_perf.css/NestingIdentInvalidValue/NestingIdentInvalidValue.html
To opt-out of further automatically started bisections for this issue, please
add the <b>Chromeperf-Auto-BisectOptOut</b> label.
br...@gmail.com <br...@gmail.com> #7
<b>Started sandwich culprit verification process.</b>
culprit verification workflow keys: ['projects/62121018386/locations/us-central1/workflows/sandwich-verification-workflow-prod/executions/9c581e78-2703-4ec8-b526-034708263113']
hu...@google.com <hu...@google.com> #8
<b>Updating trunk VERSION from 7111.0 to 7112.0</b> by chrome-official-brancher@chops-service-accounts.iam.gserviceaccount.com
NestingIdentInvalidValue: 12.99 → 14.37 (+1.39) (+10.7%)
Understanding performance regressions:
Benchmark documentation link:
You can view the full results and re-run the Pinpoint job at:
If you think Pinpoint blamed the wrong commit, please add issue to
`Chromeperf-CulpritDetection-NeedsAttention` (hotlist:5670048) and
unassign yourself so that a sheriff can help diagnose.
br...@gmail.com <br...@gmail.com> #9
I ended up buying an actual Nexus 10 to debug this issue. The photos have the correct orientation. Attached are pictures (the wood figurines).
For the Zebra ET-51, I did a little more digging and realized a little more of what was actually happening here. Initially, the preview looked "zoomed in", but after setting the attribute app:scaleType="fitCenter"
on PreviewView
, it became clear that the orientations of the preview and the photo actually do match. However, the rotation is incorrect. Attached are pictures (the dogs).
hu...@google.com <hu...@google.com> #10
Hi Bryan,
Glad to see the issue on the Nexus 10 has been resolved. It seems your emulator had an issue.
Regarding the Zebra tablet, are the preview and capture results different from the native camera app?
br...@gmail.com <br...@gmail.com> #11
The Zebra tablet's native camera has the correct orientation for the preview and the actual photo (ie. holding the tablet in portrait results in a portrait preview and portrait photo, holding the tablet in landscape results in a landscape preview and landscape photo).
br...@gmail.com <br...@gmail.com> #12
While we are waiting on a fix, I contacted Zebra and their engineers have helped us find a solution I can tolerate. TO BE CLEAR: THIS IS STILL A BUG AND Y'ALL SHOULD FIX IT. But my ability to assist in any debugging is soon ending, so if y'all want me to provide any more help, it is now or never. Our current band-aid solution requires device specific code and does not fully meet our expectations, but it is better than before.
It seems like setting a target aspect ratio for both the preview and the resulting photo do not behave properly for the Zebra ET51. When we do not set the target aspect ratio, it appears as though CameraX will default to a 4:3 aspect ratio. Thankfully, it is oriented correctly for the ET51. So while we still do have decent mismatch between the screen's aspect ratio and the camera's aspect ratio, the difference is less than before. Attached are some pictures for reference. The photos are using the CameraXBasic
sample app with a patch (also attached) applied.
TL;DR: do not use setTargetAspectRatio()
for the Zebra ET51 tablet
ch...@google.com <ch...@google.com> #13
For the Nexus 10 device, actually the result is still incorrect but it is not so obvious as the ET51 device. By the provided capture photo in
For the ET51 tablet device, I think it should support some portrait sizes. The bug in SupportedSurfaceCombination.java#376 would cause those portrait sizes to be selected in priority.
The workaround mentioned in
ch...@google.com <ch...@google.com>
ku...@walmart.com <ku...@walmart.com> #15
Just wanted to let ya'll know that when we updated to the latest library versions found setTargetAspectRatio()
or not. Attached is the preview using the latest library versions. When we reverted back to 1.0.0-beta07 & 1.0.0-alpha14, the workaround described in
ch...@google.com <ch...@google.com> #16
Thanks for providing the information. In the latest 1.0.0-beta08 release, we do some cleanup related to the default aspect ratio setting . The default aspect ratio now is also the same as calling setTargetAspectRatio(). For this buganizer issue, we're working on a CL to fix the target aspect ratio issue on tablets and it is targeted to be included in the next release. Please refer to
To confirm the issue root cause is exactly the same as what I analyzed in
WindowManager windowManager = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
CameraCharacteristics characteristics = cameraManager.getCameraCharacteristics(cameraId);
StreamConfigurationMap map = characteristics.get(CameraCharacteristics.SCALER_STREAM_CONFIGURATION_MAP);
Size[] outputSizes = map.getOutputSizes(ImageFormat.PRIVATE);
ku...@walmart.com <ku...@walmart.com> #17
Thanks so much. We have used the code snippet provided and gathered the information you need. We believe that the first array is the back camera and the second array is the front camera for the ET51 Tablet:
[4160x3120,4000x3000,3840x2160,3264x2448,3200x2400,2976x2976,2592x1944,2688x1512,2048x1536,1920x1080,2560x800,1600x1200,1440x1080,1280x960,1280x768,1280x720,1200x1200,1280x480,1280x400,1024x768,800x600,864x480,800x480,720x480,640x480,640x360,480x640,480x360,480x320,352x288,320x240,240x320,176x144,160x120,144x176]
[2592x1944,2048x1536,1920x1080,2560x800,1600x1200,1440x1080,1280x960,1280x768,1280x720,1200x1200,1280x480,1280x400,1024x768,800x600,864x480,800x480,720x480,640x480,640x360,480x640,480x360,480x320,352x288,320x240,240x320,176x144,160x120,144x176]
ch...@google.com <ch...@google.com> #18
ap...@google.com <ap...@google.com> #19
Branch: androidx-master-dev
commit f7601b432650179fe0e780e603d0bfbc7328b9f1
Author: charcoalchen <charcoalchen@google.com>
Date: Mon Aug 24 15:16:23 2020
Fix target aspect ratio issue on tablet devices
Whether the sensor orientation is landscape should not be determined by the sensor orientation degrees value. Using SENSOR_INFO_PIXEL_ARRAY_SIZE value to determine it.
Relnote:"Fixed target aspect ratio issue on tablet devices. A 16:9 size should be selected when the target aspect ratio is set as AspectRatio.RATIO_16_9."
Bug: 151969438
Test: ./gradlew bOS
Change-Id: Ib7fcfae000fb16010c2246f22a7e6f6efb8021aa
M camera/camera-camera2/src/main/java/androidx/camera/camera2/internal/SupportedSurfaceCombination.java
M camera/camera-camera2/src/test/java/androidx/camera/camera2/internal/SupportedSurfaceCombinationTest.java
Description
CAMERA APPLICATION NAME AND VERSION: CameraXBasic (
ANDROID OS BUILD NUMBER: 8.1.0
DEVICE NAME: Nexus 10 Emulator, Zebra ET51
DESCRIPTION: When the tablet preview is portrait oriented, the resulting photo is landscape.
STEPS TO REPRODUCE:
1. Put the tablet in portrait
2. Launch the demo app
3. Take a picture
OBSERVED RESULTS: Resulting photo is landscape
EXPECTED RESULTS: Resulting photo is portrait
REPRODUCIBILITY: 5 of 5
ADDITIONAL INFORMATION: There might be an associated bug: