Status Update
Comments
nj...@google.com <nj...@google.com> #2
This is a particularly hard device to come by - do you happen to have access to the device? If so could you provide us with the output of: adb shell dumpsys media.camera > info.txt
Thanks!
an...@google.com <an...@google.com> #3
Stacktrace:
Caused by: java.lang.IllegalArgumentException: Can not get supported output size under supported maximum for the format: 34
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes(SupportedSurfaceCombination.java:355)
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions(SupportedSurfaceCombination.java:197)
at androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions(Camera2DeviceSurfaceManager.java:198)
at androidx.camera.core.CameraX.calculateSuggestedResolutions(CameraX.java:943)
at androidx.camera.core.CameraX.bindToLifecycle(CameraX.java:293)
at androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle(ProcessCameraProvider.java:227)
Below are some findings based on our debugging
When Dex is connected
previewConfig.getMaxResolution() is returning "731x411" as maxSize.
Inside Preview.Builder.build() -> Default_MAX_resolution is set to "CameraX.getSurfaceManager().getPreviewSize()" which is 731x411
this is being picked as maxSize.
While rendering maxSize is 731x411 and minSize is 640x480 and below are available outputSizes
0 = {Size@11860} "4032x3024"
1 = {Size@11861} "3984x2988"
2 = {Size@11862} "4032x2268"
3 = {Size@11863} "3024x3024"
4 = {Size@11864} "2976x2976"
5 = {Size@11865} "3840x2160"
6 = {Size@11866} "3264x2448"
7 = {Size@11867} "4032x1960"
8 = {Size@11868} "2880x2160"
9 = {Size@11869} "3264x1836"
10 = {Size@11870} "2160x2160"
11 = {Size@11871} "2560x1440"
12 = {Size@11872} "2224x1080"
13 = {Size@11873} "2048x1152"
14 = {Size@11874} "1920x1080"
15 = {Size@11875} "1440x1080"
16 = {Size@11876} "1088x1088"
17 = {Size@11877} "1280x720"
18 = {Size@11878} "1024x768"
19 = {Size@11879} "1056x704"
20 = {Size@11880} "960x720"
21 = {Size@11881} "960x540"
22 = {Size@11882} "720x720"
23 = {Size@11883} "800x450"
24 = {Size@11884} "720x480"
25 = {Size@11885} "640x480"
26 = {Size@11886} "352x288"
27 = {Size@11887} "320x240"
28 = {Size@11888} "256x144"
29 = {Size@11889} "176x144"
and couldn't find any size in this range.
When Dex not connected
minsize = 640x480
maxsize = 1920x1080
0 = {Size@11836} "4032x3024"
1 = {Size@11837} "3984x2988"
2 = {Size@11838} "4032x2268"
3 = {Size@11839} "3024x3024"
4 = {Size@11840} "2976x2976"
5 = {Size@11841} "3840x2160"
6 = {Size@11842} "3264x2448"
7 = {Size@11843} "4032x1960"
8 = {Size@11844} "2880x2160"
9 = {Size@11845} "3264x1836"
10 = {Size@11846} "2160x2160"
11 = {Size@11847} "2560x1440"
12 = {Size@11848} "2224x1080"
13 = {Size@11849} "2048x1152"
14 = {Size@11850} "1920x1080"
15 = {Size@11851} "1440x1080"
16 = {Size@11852} "1088x1088"
17 = {Size@11853} "1280x720"
18 = {Size@11854} "1024x768"
19 = {Size@11855} "1056x704"
20 = {Size@11856} "960x720"
21 = {Size@11857} "960x540"
22 = {Size@11858} "720x720"
23 = {Size@11859} "800x450"
24 = {Size@11860} "720x480"
25 = {Size@11861} "640x480"
26 = {Size@11862} "352x288"
27 = {Size@11863} "320x240"
28 = {Size@11864} "256x144"
29 = {Size@11865} "176x144"
and we have 12 available sizes in this range
Camera2DeviceSurfaceManager.java:: getPreviewSize()
mCameraSupportedSurfaceCombinationMap.get(cameraId).getSurfaceDefinition().getPreviewSize() = "1920x1080"
cameraId=0
an...@google.com <an...@google.com> #4
The issue root cause is that CameraX will default filter out sizes smaller than 640x480. For Preview, the max size will be limited to under display size. I checked the HW spec info for the issue related devices. Display size of FUJITSU F-04J/F-05J is 360x640. That will result int that no size exists in the conditions that is larger or equal to 640x480 and smaller or equal to 360x640.
A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.
For device FUJITSU arrowsM04, I checked its HW spec info and its display size I found is 1280x720. It seems that the problem should not exist in the device.
Could you confirm that the problem exist on arrowsM04 device? What will be the returned value when using Display#getRealSize to obtain the display size?
nj...@google.com <nj...@google.com> #5
> A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.
OK. I will try it.
> Could you confirm that the problem exist on arrowsM04 device?
We receive the crash report (Crashlytics) that this crash has occurred on arrowsM04.
We don't have this device so we can't confirm that the problem really exist on arrowsM04.
> What will be the returned value when using Display#getRealSize to obtain the display size?
We can't investigate it for the same reason.
Thank you.
nj...@google.com <nj...@google.com> #6
This issue happened on devices that the display size is smaller than 640x480. In original auto-resolution mechanism, supported sizes smaller than 640x480 will be default filter out.
The auto-resolution mechanism encodes the guaranteed configurations tables in CameraDevice#createCaptureSession(SessionConfiguration). It defines that the PREVIEW size is the small one of the device display size and 1080p. The PREVIEW size will be the maximal size limitation for Preview use case. The reason it limits the size to display size and 1080p is the stream output in display size or 1080p has been able to provide good enough preview quality. Therefore, auto-resolution mechanism will limit the selected size to be smaller than the small one of the device display size and 1080p.
With above two conditions, in this issue, all sizes smaller than 640x480 have been filter out, therefore, there is no size smaller than the display size 320x240 can be selected to use. And cause the exception.
Solution:
When the display size is smaller than 640x480, auto-resolution mechanism won't filter out those small sizes smaller than 640x480. This makes those small size be left and can be selected for the Preview use case on small display devices.
The solution has been merged and will be included in next CameraX release.
an...@google.com <an...@google.com> #7
Hello.
This crash still occurs.
- CAMERAX VERSION: 1.0.0-beta4
- ANDROID OS BUILD NUMBER: Android 7.1.1
- DEVICE NAME: FUJITSU F-02H
We receive following crash report from FUJITSU F-02H. So far We have received this crash report only from F-02H.
java.lang.IllegalArgumentException
Can not get supported output size under supported maximum for the format: 34
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes (SupportedSurfaceCombination.java:349)
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions (SupportedSurfaceCombination.java:197)
androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions (Camera2DeviceSurfaceManager.java:198)
androidx.camera.core.CameraX.calculateSuggestedResolutions (CameraX.java:949)
androidx.camera.core.CameraX.bindToLifecycle (CameraX.java:351)
androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle (ProcessCameraProvider.java:230)
(our application's package name).CameraFragment.bindCameraUseCases (CameraFragment.java:174)
nj...@google.com <nj...@google.com> #8
Could you help to provide the following information to clarify the issue?
1. Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
2. Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
an...@google.com <an...@google.com> #9
- Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
Yes
- Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
Since we don't have this device, we'll try to collect this information in the next version of our app. The next version will be released later this month.
nj...@google.com <nj...@google.com> #10
Hello.
- Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
We have collected the output of the device where the crash occurs.
Device1
- Model : arrows Be F-05J
- Android Version : 7.1.1
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
Device2
- Model : Fujitsu arrows M04
- Android Version : 7.1.1
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
Additional Information
CameraX version : 1.0.0-beta04
We collect the supported output sizes by following code.
val errorString = buildString {
append("The supported output sizes of ImageFormat.PRIVATE: ")
(requireContext().getSystemService(Context.CAMERA_SERVICE) as CameraManager).apply {
cameraIdList.forEachIndexed { index, cameraId ->
val msg = if (VERSION.SDK_INT >= VERSION_CODES.M) {
val configurationMap =
getCameraCharacteristics(cameraId).get(CameraCharacteristics.SCALER_STREAM_CONFIGURATION_MAP)
val sizes = configurationMap?.getOutputSizes(ImageFormat.PRIVATE)
"CameraId $index: ${sizes?.joinToString(" ,")}"
} else {
"CameraId $index: This device version is under M."
}
append(msg)
}
}
}
an...@google.com <an...@google.com> #11
nj...@google.com <nj...@google.com> #12
I tried to find the device specs and both 720x1280
size display. For the camera id 0 device, it is a different case that the display size is larger than 640x480
but the device only supports a 480x480
size. The case also caused the same IllegalArgumentException and was also fixed by 1.0.0-beta04
release. Before 480x480
size would be filtered out and then caused the IllegalArgumentException. After it was merged, the 640x480
size threshold was removed and then the 480x480
size would be kept and selected to use.
It looks like 1.0.0-beta04
release had been used to collect the supported sizes information. But the issue should have been fixed by 1.0.0-beta04
release. Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
CameraX's 1.0.0-beta04
version. Maybe you can also consider to upgrade to the latest 1.0.0-rc01
version for your application. Thanks.
an...@google.com <an...@google.com> #13
Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
We collect informations only from the device on which IllegalArgumentException happened.
Our latest app uses CameraX version 1.0.0-beta10
and this issue still occurres.
However we don't receive crash report from Fujitsu arrows Be F-05J
or Fujitsu arrows M04
so far. (This doesn't mean this issue is fixed on these devices because our app is heavily rely on camera so these device's user wouldn't use our app anymore.)
Instead, we receive crash report from
- Model : Fujitsu F-03K
- Android Version : 7.1.2
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0 : 480x480
CameraId 1 : 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
nj...@google.com <nj...@google.com> #14
I missed some settings when I simulated the issue by robolectric test so that I was not able to reproduce it. Now, I can reproduce the issue if the device only supports one 480x480 resolution. I'm working on the solution and target to make it included in next release.
an...@google.com <an...@google.com> #15
Branch: androidx-main
commit 69d15dff7bb857ee33a0f643ff42a0f8bc475ab2
Author: charcoalchen <charcoalchen@google.com>
Date: Fri Jan 08 18:30:03 2021
Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.
Do not filter out sizes smaller than 640x480 when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.
Relnote:"Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480."
Bug: 150506192
Test: SupportedSurfaceCombinationTest
Change-Id: I2a63ce8e2ad42a9cc060c8635ac3603bf440b1ec
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
nj...@google.com <nj...@google.com> #16
an...@google.com <an...@google.com> #17
Modifier.layout { measurable, constraints ->
val placeable = measurable.measure(constraints)
layout(placeable.width, placeable.height) {
placeable.place(0, myState.value)
}
}
nj...@google.com <nj...@google.com> #18
It is up to the developer use case. If they are never translating the child composable after the fact, then this implementation is fine as is. However, if they intend on animating it afterwards then we should be pointing them to use Modifier.translate instead.
mo...@google.com <mo...@google.com> #19
I added Matvei because I think he preferred opacity over alpha.
We can't remove offset
/offsetPx
as they are now as they are layout parameters and don't require a layer. I don't think we want to be adding layers for each offset
, do we?
I think it is fine to have separate modifiers for rotation and scaling. We may even prefer to make only the simple versions (rotationZ and scaleX = scaleY) and require developers to use the graphicsLayer
modifier for the fancier versions. They are convenience methods, after all, and only 1 liners.
I don't see any benefit from adding a translation
modifier. I doubt it will be common use and, again, a two-liner if the developer makes it themselves. Most commonly, the developer will use offset
+ graphicsLayer
to achieve the same thing.
nj...@google.com <nj...@google.com> #20
We still need translation to do efficient movement/scrolling of children within a container. Additionally it is useful for modifying a composable in response to touch gestures (drag and drop). Using offset for these requires layout + measurement passes instead of just an efficient invalidation call (draw commands are not re-recorded).
I do like the 1 liners however, I am concerned that it forces developers to think of order of operations for multiple transformations which may introduce additional/unnecessary layers as a result. But generally speaking keeping the names consistent with the fields (i.e. using alpha vs opacity) is clearer.
nj...@google.com <nj...@google.com> #21
Another thing to consider is how Modifier.offset
is consumed within a composable container. For example we could have a FlexLayout
composable that will always attempt to layout children from left to right until the available width is consumed. Then subsequent children will be positioned below the previous ones. I believe it would make sense for offset to contribute to the "reflowing" of content to the next line. However, if we wanted to translate content to be drawn on top and not contribute to reflowing of content (ex. for a drag and drop UI or text marquee) we would need to leverage translation here. While offset and translate are similar to do serve different use cases.
mo...@google.com <mo...@google.com> #22
offset should not affect the measure pass, but it will have to rerun placement.
With respect to alpha/opacity, these terms may both be consistent, but with different surfaces. It may be that Material Design specifies "opacity," while the graphics engine specifies "alpha." I think that in this case, we should choose whichever is more familiar to the application developer.
nj...@google.com <nj...@google.com> #23
offset should not affect the measure pass, but it will have to rerun placement.
The contents will measure the same way however in the FlexLayout example, an offset modifier placed on a single child will affect the layout placement of the other siblings in the composable container.
I think that in this case, we should choose whichever is more familiar to the application developer.
Should we stick to alpha to be consistent with View.setAlpha? We only used opacity within the Drawable#getOpacity
API which used to be a hint for an internal optimization in the framework that is no longer done anymore.
mo...@google.com <mo...@google.com> #24
Offset does not affect the placement of other siblings. It simply offsets the child.
The language around opacity may come from the Material spec. I am unsure and want Matvei's input here.
an...@google.com <an...@google.com> #25
ma...@google.com <ma...@google.com> #26
Hello! I used to prefer opacity since you are modifying the opacity of the component, not the "alpha channel". As far as I'm aware, material also prefers opacity, but since the API we're making here are not purely material, this is not super relevant I'd say.
Overall for me it's 60/40 preference for opacity over alpha. Also plus for opacity is that it's already familiar to compose devs. I will leave this decision up to you folks since I would be happy to have any of whose, especially without draw prefix :)
nj...@google.com <nj...@google.com> #27
Layer is a design language agnostic API so I am not sure we should be leveraging material naming conventions here. Different design languages (holo, material, etc.) should be built on the foundation building blocks rather than building the foundation on design naming conventions. If we need to the material lib could have a typealias for Modifier.opacity that maps to alpha if we need to keep naming consistency. Also if we are helping to onboard traditional android framework developers keeping alpha here would help for discoverability.
For simplicity I'm thinking maybe we could just have the simplest shadow, alpha, scale and rotate APIs without including pivot point. I am still concerned with extraneous layer calls because it is more likely to do Modifier.scale(2f).rotate(45)
than to do Modifier.drawLayer{ /* block */}.drawLayer{/* block */}
. The overhead of this API surface scales worse as additional transformations are added on.
That being said, what about the following convenience APIs?
Modifier.shadow(elevation: Dp, shape: Shape, clip: Boolean) // same as Modifier.drawShadow just drop the draw prefix
Modifier.alpha(alpha: Float)
Modifier.rotate(degrees: Float) // (aka rotateZ) rotates about the center of the composable
Modifier.scale(scaleX: Float, scaleY: Float) // scales the horizontal/vertical dimensions about the center of the composable
Modifier.scale(scale: Float) // same as above except scales both horizontal and vertical by the same scale factor
All other use cases we can point the developer to use the Modifier.drawLayer API to rotateX/Y, rotate with a different pivot point, translate, configure camera distance, etc.
Thoughts?
al...@gmail.com <al...@gmail.com> #28
Hehe... naming is always so complicated. :)
My 2 cents... I'm kind of fine with either "alpha" or "opacity" TBH. On one hand, "alpha" is nice because it's similar to what already exists in Android with View#setAlpha()
. On the other hand, opacity is not difficult to understand (and is even used in SVG to apply opacity to nodes in the same way you apply alpha to Views on Android).
I tend to agree with you all that the 'draw' prefix is not necessary and goes against the conventions of other similar APIs.
an...@google.com <an...@google.com> #29
ap...@google.com <ap...@google.com> #30
Branch: androidx-master-dev
commit b89a33a434327022fb96fa4479686fe4cd826f48
Author: Nader Jawad <njawad@google.com>
Date: Thu Nov 19 18:44:23 2020
Added convenience APIs for layer transforms
Relnote: "Added Modifier.scale/rotate
APIs as conveniences for drawLayer.
--Renamed Modifier.drawOpacity to Modifier.alpha
--Renamed Modifier.drawShadow to Modifier.shadow"
Fixes: 173208140
Test: Added tests to DrawLayerTest
Change-Id: I264ca72b36ea62fd615436849203895ed742fa1e
M compose/animation/animation/samples/src/main/java/androidx/compose/animation/samples/AnimatedValueSamples.kt
M compose/animation/animation/src/commonMain/kotlin/androidx/compose/animation/Crossfade.kt
M compose/material/material/integration-tests/material-demos/src/main/java/androidx/compose/material/demos/ColorPickerDemo.kt
M compose/material/material/src/androidAndroidTest/kotlin/androidx/compose/material/BottomSheetScaffoldTest.kt
M compose/material/material/src/androidAndroidTest/kotlin/androidx/compose/material/ScaffoldTest.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/BottomNavigation.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/TextFieldImpl.kt
M compose/ui/ui/api/current.txt
M compose/ui/ui/api/public_plus_experimental_current.txt
M compose/ui/ui/api/restricted_current.txt
M compose/ui/ui/samples/src/main/java/androidx/compose/ui/samples/AlphaSample.kt
M compose/ui/ui/samples/src/main/java/androidx/compose/ui/samples/RotateSample.kt
M compose/ui/ui/samples/src/main/java/androidx/compose/ui/samples/ScaleSample.kt
M compose/ui/ui/samples/src/main/java/androidx/compose/ui/samples/ShadowSample.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/draw/AlphaTest.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/draw/DrawLayerTest.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/draw/ShadowTest.kt
A compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/draw/Alpha.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/draw/Rotate.kt
A compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/draw/Scale.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/draw/Shadow.kt
Description
For example when user wants to add a shadow they will probably write Modifier.shadow. Our overload currently called Modifier.drawShadow(). Should we get rid from "draw" here? I think yes.
The same is true for Modifier.drawOpacity(). But here it is even more interesting. Do people think about that as opacity or alpha? In Views we had setAlpha. Should we rename it to Modifier.alpha() instead?
Modifier.clip() already has no "draw" in its name.
On a related note I think we should also provide Modifier.rotation() and Modifier.scale(), I saw people asking on how to do rotation in Compose in kotlinslack more then once. I suggest to not add Modifier.translation() though as I already mention in the doc recently it would be impossible to understand when to use Modifier.offsetPx() and when Modifier.translation().
Wdyf?