Status Update
Comments
cl...@google.com <cl...@google.com>
ve...@gmail.com <ve...@gmail.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!
kp...@gmail.com <kp...@gmail.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
hl...@gmail.com <hl...@gmail.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?
ks...@gmail.com <ks...@gmail.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.
ri...@gmail.com <ri...@gmail.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.
sh...@gmail.com <sh...@gmail.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)
ej...@gmail.com <ej...@gmail.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).
gu...@gmail.com <gu...@gmail.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.
de...@gmail.com <de...@gmail.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)
}
}
}
op...@gmail.com <op...@gmail.com> #11
ma...@gmail.com <ma...@gmail.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.
ra...@gmail.com <ra...@gmail.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
Yu...@icloud.com <Yu...@icloud.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.
ai...@googlemail.com <ai...@googlemail.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
ri...@gmail.com <ri...@gmail.com> #16
ta...@gmail.com <ta...@gmail.com> #17
ez...@gmail.com <ez...@gmail.com> #18
+1
Android 28 (Pie) added support for custom shadows. It's very strange that, 2 years later, MDC for Android still don't support it.
And it's even stranger why a freshly made UI toolkit like Compose did not account for custom shadows.
mo...@google.com <mo...@google.com> #19
Which features do you want from the shadow that Compose doesn't provide? I thought that we had supported most of Android's shadow capabilities.
nj...@google.com <nj...@google.com> #20
I think the main feature request is to be able to color the shadows. Right now they are always the grey/blackish ones. Framework introduced both ambient and spot color shadows back in API level 28 I believe
ai...@gmail.com <ai...@gmail.com> #21
I don't think it's a problem with the support of Android Framework shadows, it's already a problem on the framework itself, the main request (at least for me) to implement custom shadows only for Compose which are more flexible than Framework ones, even if they are not as performant as ones provided by the framework, after all, ad-hoc implementation will be probably even less performant than officially supported modifier for shadows.
Maybe it worth keeping drawShadow as it is and introduce an additional modifier like drawCustomShadow, so it will be more clear that it doesn't use an optimized version of shadows.
ja...@gmail.com <ja...@gmail.com> #22
Colors, positions and offsets. For all API levels and desktop as previous comment said.
nj...@google.com <nj...@google.com> #23
It is important to note that shadows in the framework are consistent with a singular light source placed in a virtual space above the top of the display. This ensures that shadows are rendered consistently with content to the left/right closer/further away from the content as well. This configuration is more part of the rendering environment vs configuration of parameters for a single drawing instruction like drawRect. This is what makes positions and offsets less likely to be configurable vs color information.
ja...@gmail.com <ja...@gmail.com> #24
IMO a multiplatform library should allow more things, not only material one.
If I want to create a neumorphism theme I will have to do from scratch.
Why all future targets of compose have to place the light in the same exact point?
I can understand how shadows have to work if using material, but the generic one should be more flexible.
ai...@gmail.com <ai...@gmail.com> #25
Such behavior of shadows makes sense in the context of Material design paradigm but makes it less controllable by developers.
When in most of cases I want to replicate a design from my design team, and shadow is just an instrument for me to emulate shadows from their design tool (photoshop/figma/sketch etc), and they not only do not use single light source, but often used shadows in different cases and with different settings, which now is hard to emulate (or possible, but tedious and require usage of custom drawables or custom rendering)
I would expect drawShadow modifier (or some additional) which works closer to
ri...@gmail.com <ri...@gmail.com> #26
That's right. This design requirement exists between many development teams, should not allow everyone to follow Material Design, this will reject many people, I really hope that Compose can do better than Flutter, in the current point of view, Compose is really bad than Flutter in addition to Kotlin this feature..
m....@futuremind.com <m....@futuremind.com> #27
I strongly support that - shadows are a general design thing, not material design specific. Compose allows for theming outside of material design paradigm, same principle should be applied to shadows.
se...@gmail.com <se...@gmail.com> #28
[Deleted User] <[Deleted User]> #29
wi...@gmail.com <wi...@gmail.com> #30
gu...@gmail.com <gu...@gmail.com> #31
ig...@gmail.com <ig...@gmail.com> #32
df...@hotmail.com <df...@hotmail.com> #33
wo...@gmail.com <wo...@gmail.com> #34
[Deleted User] <[Deleted User]> #35
li...@gmail.com <li...@gmail.com> #36
[Deleted User] <[Deleted User]> #37
se...@gmail.com <se...@gmail.com> #38
Please stop spamming "+1". This only creates noise in notifications. Press the ⭐ button and stay calm.
sn...@gmail.com <sn...@gmail.com> #39
ch...@gmail.com <ch...@gmail.com> #40
do...@gmail.com <do...@gmail.com> #41
ke...@gmail.com <ke...@gmail.com> #42
ra...@gmail.com <ra...@gmail.com> #43
ne...@gmail.com <ne...@gmail.com> #44
ci...@gmail.com <ci...@gmail.com> #45
du...@gmail.com <du...@gmail.com> #46
ni...@gmail.com <ni...@gmail.com> #47
tu...@gmail.com <tu...@gmail.com> #48
mb...@gmail.com <mb...@gmail.com> #49
kt...@threenitas.com <kt...@threenitas.com> #50
na...@gmail.com <na...@gmail.com> #51
la...@gmail.com <la...@gmail.com> #52
ze...@gmail.com <ze...@gmail.com> #53
+1
zo...@gmail.com <zo...@gmail.com> #54
ry...@gmail.com <ry...@gmail.com> #55
Do not +1.
Star the issue instead. This isn't a forum.
sh...@gmail.com <sh...@gmail.com> #56
ra...@gmail.com <ra...@gmail.com> #57
so...@gmail.com <so...@gmail.com> #58
di...@gmail.com <di...@gmail.com> #59
zh...@gmail.com <zh...@gmail.com> #60
ta...@mercury.com <ta...@mercury.com> #61
Here's a change request to add the ambientShadowColor
and spotShadowColor
layer properties and expose them via GraphicsLayerScope
:
If desired, the Surface
, Card
, Button
, etc. layouts could then expose these values before passing them on to GraphicsLayerModifier
, but this is usable with custom layouts in non-Material design systems.
ri...@gmail.com <ri...@gmail.com> #62
Unfortunately, they need to run on android greater than sdk28, which is far from androidx compose's argument for minimum support for sdk21.
I mean compose is a androidx ui toolkit rather than a system-level framework, so it should be backwards compatible, at least compatible to the same level as the compose core, instead of letting people implement different codes for different android versions when using it.
ta...@mercury.com <ta...@mercury.com> #63
Re: #62:
Compose already supports RenderEffect for blurring graphics layers, which was added in API 31, so that argument wouldn't be consistent with what Compose currently supports.
ri...@gmail.com <ri...@gmail.com> #64
Compose already supports RenderEffect for blurring graphics layers, which was added in API 31, so that argument wouldn't be consistent with what Compose currently supports.
emm...Yes, I know that, maybe it is the technical difficulties of the lower version implementation that makes it impossible to use other methods to achieve backwards compatibility, so I am a little disappointed
po...@gmail.com <po...@gmail.com> #65
na...@gmail.com <na...@gmail.com> #66
ks...@gmail.com <ks...@gmail.com> #67
+1
ou...@gmail.com <ou...@gmail.com> #68
de...@gmail.com <de...@gmail.com> #69
al...@gmail.com <al...@gmail.com> #70
an...@gmail.com <an...@gmail.com> #71
su...@gmail.com <su...@gmail.com> #72
ap...@google.com <ap...@google.com> #73
Branch: androidx-main
commit eb5a07a3e10da9818d386fa9533372fd4316ddaa
Author: Nader Jawad <njawad@google.com>
Date: Fri Mar 04 16:30:21 2022
Minor tweaks to support shadow colors
Updated ReplaceWith usage to pull in proper import
Ran ignoreApiChange to handle deprecationlevel hidden
deprecation instances.
Relnote: "Updated shadow/ambient colors to be trailing
parameters of Modifier.graphicsLayer for API compatibility
Added default implementations to shadow/ambient color on
GraphicsLayerScope to ensure non-breaking API changes"
Moved spot/ambientShadowColor parameters to the end
of argument lists to avoid breaking existing usages
of Modifier.graphicsLayer
Bug: 160665122
Test: re-ran compose tests
Change-Id: I3f8645838aa5b8dc9e5ef22dc112329abcc46b55
M compose/ui/ui/api/restricted_current.ignore
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/graphics/GraphicsLayerScope.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/OwnedLayer.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/RenderNodeLayer.android.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/AndroidLayoutDrawTest.kt
M compose/ui/ui/src/desktopTest/kotlin/androidx/compose/ui/platform/SkiaLayerTest.kt
M compose/ui/ui/src/skikoMain/kotlin/androidx/compose/ui/platform/SkiaLayer.skiko.kt
M compose/ui/ui/api/current.txt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/draw/Shadow.kt
M compose/ui/ui/src/test/kotlin/androidx/compose/ui/node/LayoutNodeTest.kt
M compose/ui/ui/api/current.ignore
M compose/ui/ui/api/restricted_current.txt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/RenderNodeApi23.android.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/ViewLayer.android.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/input/pointer/HitPathTrackerTest.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/graphics/GraphicsLayerModifier.kt
M compose/ui/ui/api/public_plus_experimental_current.txt
ap...@google.com <ap...@google.com> #74
Branch: androidx-main
commit 8edcbf9e0b6d057d1108040206dff5d5dae70049
Author: Tad Fisher <tadfisher@gmail.com>
Date: Thu Jan 20 12:54:38 2022
Add ambientShadowColor and spotShadowColor layer properties
Relnote: compose-ui: Add ambientShadowColor and spotShadowColor properties to GraphicsLayerScope
Test: GraphicsLayerModifierTest.kt, ShadowTest.kt
Bug: 160665122
Change-Id: I1ba1a4da6942817ad8593fc9052060d7c48b3064
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/graphics/GraphicsLayerScope.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/AndroidLayoutDrawTest.kt
M compose/ui/ui/src/desktopTest/kotlin/androidx/compose/ui/platform/SkiaLayerTest.kt
M compose/ui/ui-android-stubs/api/public_plus_experimental_current.txt
M compose/ui/ui/src/skikoMain/kotlin/androidx/compose/ui/platform/SkiaLayer.skiko.kt
M compose/ui/ui/api/current.txt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/RenderNodeApi29.android.kt
M compose/ui/ui/src/test/kotlin/androidx/compose/ui/node/LayoutNodeTest.kt
M compose/ui/ui-android-stubs/api/current.txt
M compose/ui/ui-android-stubs/src/main/java/android/view/RenderNode.java
M compose/ui/ui/api/restricted_current.txt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/DeviceRenderNode.android.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/ViewLayer.android.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/graphics/GraphicsLayerModifier.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/input/pointer/HitPathTrackerTest.kt
M compose/ui/ui-android-stubs/api/restricted_current.txt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/OwnedLayer.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/RenderNodeLayer.android.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/draw/GraphicsLayerModifierTest.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/draw/Shadow.kt
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/draw/ShadowTest.kt
M compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/RenderNodeApi23.android.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/node/LayoutNodeWrapper.kt
M compose/ui/ui/api/public_plus_experimental_current.txt
sk...@stripe.com <sk...@stripe.com> #75
ka...@dext.com <ka...@dext.com> #76
ma...@gmail.com <ma...@gmail.com> #77
pa...@gmail.com <pa...@gmail.com> #78
di...@mindera.com <di...@mindera.com> #79
ti...@gmail.com <ti...@gmail.com> #80
+1
st...@gmail.com <st...@gmail.com> #81
ma...@gmail.com <ma...@gmail.com> #82
ci...@gmail.com <ci...@gmail.com> #83
ca...@gmail.com <ca...@gmail.com> #84
ph...@gmail.com <ph...@gmail.com> #85
It's pretty weird, if I understand the comment
I understand this has to do with Material single light source, but I believe that Compose as a UI framework should not be restricted by Material guidelines. Elevation is something only Material related, and it seems more appropriate for Modifier.shadow(elevation = ...)
to be inside androidx.compose.material
, and androidx.compose.material
could have a modifier that is independent of light source or elevation, and can be configured.
It is very strange to limit this possibility, because for the most part there are no restrictions on creating non Material UI on Android. Often apps are made with platform-independent designs, and it should be possible to create them as designed.
The only possibility to draw a shadow, which I found, on older devices requires to turn off hardware acceleration, as well as has a number of limitations during the animation.
This is by far the most popular issue of Compose, which shows how much people really need this kind of feature.
mi...@gmail.com <mi...@gmail.com> #86
On top of it I also don't understand why compose must be a limb version of View system. If a feature is not in View we don't get something here. For example we cannot use Concave shapes although it worked on early 1.0 versions but was stripped to match View system.
Same in this topic. We need new features to be able to create projects as they were designed.
we...@gmail.com <we...@gmail.com> #87
wa...@gmail.com <wa...@gmail.com> #88
mf...@gmail.com <mf...@gmail.com> #89
vc...@gmail.com <vc...@gmail.com> #90
any upd?
a....@futuremind.com <a....@futuremind.com> #91
mr...@gmail.com <mr...@gmail.com> #92
at...@gmail.com <at...@gmail.com> #93
ba...@gmail.com <ba...@gmail.com> #94
I do not understand why there has to be a virtual global singlular light source in order to cast shadows? The reason why we have that in the real world is because we do have actual physical light sources in the environment that we are able to perceive. But having a virtual one on your screen that you cannot actually see or perceive is just non-intuitive. Unless you try to also include real world light source detection, it is very stupid to have a mandatory virtual light source in the design system.
pa...@gmail.com <pa...@gmail.com> #95
Definitely agree with
This has always sounded to me as "over-designeered"
ma...@arsaga.jp <ma...@arsaga.jp> #96
+1
fr...@gmail.com <fr...@gmail.com> #97
+1 Shadows near the edge look like garbage on big screens like tablets. The "single global light" idea just doesn't look good. I only want box-shadows like css.
di...@gmail.com <di...@gmail.com> #98
te...@gmail.com <te...@gmail.com> #99
ab...@decentury.io <ab...@decentury.io> #100
+1 It's so disappointing that we can't use colored shadows in the View system, but more disappointing is that we can't do it in Compose also!
to...@gmail.com <to...@gmail.com> #101
ro...@gmail.com <ro...@gmail.com> #102
ol...@gmail.com <ol...@gmail.com> #103
eb...@gmail.com <eb...@gmail.com> #104
xd...@gmail.com <xd...@gmail.com> #105
Css supports box shadow even on android, iOS supports box shadow. Why on Earth don't we have box shadow in any way on Android/Compose?
It could be a 28+ only api, or something experimental. What I see now looks like google is pretending that elevation is enough, despite the fact that it is a material specific mechanic
da...@gmail.com <da...@gmail.com> #106
CSS box-shadow
-like Modifier
implementation
In response to
This modifier must be placed before any contents (including background
) or the shadow covers the contents.
Usage example
Draws a cyan rounded rectangle with a soft drop shadow. When pressed, the shadow is blurred even more (the animation demonstrates performance of this implementation; in fact, on my physical device, even in debug mode it looks as smooth as my eyes can see).
@Composable
fun App() {
AppTheme {
Column(
modifier = Modifier
.systemBarsPadding()
.padding(24.dp)
) {
val interactionSource = remember { MutableInteractionSource() }
val isPressed by interactionSource.collectIsPressedAsState()
Box(
modifier = Modifier
.size(100.dp, 70.dp)
.boxShadow(
color = Color.Black.copy(alpha = 0.24f),
blurRadius = animateDpAsState(
targetValue = when {
isPressed -> 12.dp
else -> 6.dp
}
).value,
offset = DpOffset(x = 0.dp, y = 4.dp),
shape = RoundedCornerShape(size = 8.dp)
)
.background(Color.Cyan)
.clickable(
interactionSource = interactionSource,
indication = LocalIndication.current
) {}
)
}
}
}
Implementation
/**
* Applies a shadow to the current box.
*
* @param color The color of the shadow.
*
* @param blurRadius The larger this value, the bigger the blur, so the shadow
* becomes bigger and lighter.
* If set to `0`, the shadow's edge is sharp.
*
* @param spreadRadius Positive values will cause the shadow to expand and grow
* bigger, negative values will cause the shadow to shrink.
*
* @param offset Offsets the shadow from the box.
*
* @param shape The shape of the box, which is applied to the shadow as well.
*
* @param clip Whether to clip the content to [shape].
*
* @param inset Whether the shadow should be inset to [shape]; otherwise, it is
* a drop shadow.
*
* @exception IllegalArgumentException Any of the following conditions holds:
* - [color] is [Color.Unspecified],
* - [blurRadius] is [Dp.Unspecified] or negative,
* - [spreadRadius] is [Dp.Unspecified],
* - [offset] is [DpOffset.Unspecified].
*/
@Stable
fun Modifier.boxShadow(
color: Color,
blurRadius: Dp,
spreadRadius: Dp = 0.dp,
offset: DpOffset = DpOffset.Zero,
shape: Shape = RectangleShape,
clip: Boolean = true,
inset: Boolean = false
): Modifier {
require(color.isSpecified) { "color must be specified." }
require(blurRadius.isSpecified) { "blurRadius must be specified." }
require(spreadRadius.isSpecified) { "spreadRadius must be specified." }
require(blurRadius.value >= 0f) { "blurRadius can't be negative." }
require(offset.isSpecified) { "offset must be specified." }
return drawWithCache {
onDrawWithContent {
if (inset)
drawContent()
drawIntoCanvas { canvas ->
val colorArgb = color.toArgb()
val hasBlurRadius = blurRadius.value.let { it.isFinite() && it != 0f }
val paint = Paint()
paint.asFrameworkPaint().let { frameworkPaint ->
if (hasBlurRadius) {
frameworkPaint.maskFilter = BlurMaskFilter(
blurRadius.toPx(),
BlurMaskFilter.Blur.NORMAL
)
}
frameworkPaint.color = colorArgb
}
val spreadRadiusPx = spreadRadius.toPx().let { spreadRadiusPx ->
when {
inset -> -spreadRadiusPx
else -> spreadRadiusPx
}
}
val hasSpreadRadius = spreadRadiusPx != 0f
val size = size
val layoutDirection = layoutDirection
val density = Density(
density = density,
fontScale = fontScale
)
val shadowOutline = shape.createOutline(
size = when {
hasSpreadRadius -> size.let { (width, height) ->
(2 * spreadRadiusPx).let { outset ->
Size(
width = width + outset,
height = height + outset
)
}
}
else -> size
},
layoutDirection = layoutDirection,
density = density
)
val nativeCanvas = canvas.nativeCanvas
val count = nativeCanvas.save()
if (inset) {
val boxOutline = when {
hasSpreadRadius -> shape.createOutline(
size = size,
layoutDirection = layoutDirection,
density = density
)
else -> shadowOutline
}
canvas.clipToOutline(boxOutline)
val bounds = boxOutline.bounds
nativeCanvas.saveLayer(
bounds.left,
bounds.top,
bounds.right,
bounds.bottom,
NativePaint().apply {
colorFilter = ColorMatrixColorFilter(
ColorMatrix(
floatArrayOf(
1f, 0f, 0f, 0f, 0f,
0f, 1f, 0f, 0f, 0f,
0f, 0f, 1f, 0f, 0f,
0f, 0f, 0f, -1f, 255f * color.alpha
)
)
)
}
)
}
canvas.translate(
dx = offset.x.toPx() - spreadRadiusPx,
dy = offset.y.toPx() - spreadRadiusPx
)
canvas.drawOutline(
outline = shadowOutline,
paint = paint
)
nativeCanvas.restoreToCount(count)
}
if (!inset)
drawContent()
}
}.run {
when {
clip -> clip(shape)
else -> this
}
}
}
fun Canvas.clipToOutline(
outline: Outline,
clipOp: ClipOp = ClipOp.Intersect
) {
when (outline) {
is Outline.Generic ->
clipPath(path = outline.path, clipOp = clipOp)
is Outline.Rectangle ->
clipRect(rect = outline.rect, clipOp = clipOp)
is Outline.Rounded ->
clipPath(
path = Path()
.apply { addRoundRect(outline.roundRect) },
clipOp = clipOp
)
}
}
ma...@gmail.com <ma...@gmail.com> #107
However the IDE throws the error saying method not found for - canvas.clipToOutline(boxOutline)
Any suggestions?
da...@gmail.com <da...@gmail.com> #108
Oh, sorry, I forgot to share that method as well. Just edited my post to include the implementation of clipToOutline
, which is pretty trivial.
ts...@thinkdesquared.com <ts...@thinkdesquared.com> #109
ra...@gmail.com <ra...@gmail.com> #110
We generate the entire design system with Figma, for shadows figma uses x-axis, y-axis, spread and blur just like iOS, but Android we can only use the elevations which is nothing like what they ask of us. I came across this ticket and I'm crying a little but I see that for some strange reason they don't want to provide a more personalized function. Very disappointed, let's see how I get out of this, my designers are amazed.
po...@gmail.com <po...@gmail.com> #111
gu...@gmail.com <gu...@gmail.com> #112
+1
ja...@gmail.com <ja...@gmail.com> #113
ed...@gmail.com <ed...@gmail.com> #114
+1 Compose should be more than Material. Similar to what others have stated, my design system now needs a completely different mapping from our shadow styles or use a cumbersome solution that doesn't work for anything but newer API levels.
Description
all required information.
Android Studio Build: 4.2
Version of Gradle Plugin: 4.2.0-alpha03
Version of Gradle: 6.5-rc-1
Version of Java: 8
OS: Mac OS
I was trying to implement Neumorphism design components using Compose but found limitations in the shadow modifier.
The drawShadow modifier only takes a few parameters like elevation, shape, etc. and casts the shadow based on the elevation. This implementation is oriented towards material specs. But a UI toolkit should be able to cater to other design languages as well. Just like TextField is raw and bare-bones but its implementation is provided in the Material Design module.
The shadow should also be customizable, eg. its opacity, radius, the sides, color, etc similar to the box-shadow property in CSS