Status Update
Comments
za...@gmail.com <za...@gmail.com> #2
Compose version: 0.1.0-dev06
Kotlin version: 1.3.70
cl...@google.com <cl...@google.com> #3
ku...@google.com <ku...@google.com> #4
When running in emulator the background does not appear until after the 3rd draw call. I suspect some callbacks might be involved to make the background active.
di...@google.com <di...@google.com> #5
This first call happens with hasOffets = false so the overlay/underlay is not painted on this first call. I guess we are waiting for a second layout to happen?
The call that does the painting of the background is triggered by the Choreographer which triggers a recomposition.
Is there any way we can get the first pass of tableChildren to paint? That would solve it.
lp...@google.com <lp...@google.com> #6
Unfortunately I don't think we can really change this in table, and I'm assuming this also happens for scrollable tabs, where the indicator is only drawn on the second frame.
The issue is that we don't have a good way of handling cases where composition depends on layout of children / siblings - so we need to first compose, get information on the size / position of children, and then feed that back into the composition again. I'm not super familiar with Table but I think what happens is:
Measure / place items in table -> save positioning information -> recompose and use positioning information to place and draw the decorations.
Ideally we would be able to avoid these in the components themselves, but I don't really have an idea how we can solve this currently.
di...@google.com <di...@google.com> #7
In the past, we have had a similar problem with indeterminate progress bars, where the control would only be painted on the second frame (the first one was empty because it was t=0 and we needed a second one). We could do something similar to force a recomposition once the sizes have been calculated.
If this can not be solved on the toolkit, we could use that to workaround the problem for us. It would maybe be helpful for the library to be able to signal somehow that this is needed to we do not have to force the recomposition even in cases where it's not needed.
kl...@google.com <kl...@google.com> #8
This composable was removed years ago, so this issue is obsolete.
Description
* Android Studio 4.1 Canary 1
* Build #AI-193.6494.35.41.6224510, built on February 20, 2020
* Runtime version: 1.8.0_212-release-1586-b4-5784211 x86_64
* VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
* macOS 10.15.3
* GC: ParNew, ConcurrentMarkSweep
* Memory: 7987M
* Cores: 16
* Registry: analyze.exceptions.on.the.fly=true, ide.new.welcome.screen.force=true, vcs.log.index.git=off, caches.indexerThreadsCount=16
* Non-Bundled Plugins: org.jetbrains.kotlin, izhangzhihao.rainbow.brackets
* Version of Gradle Plugin: 4.1.0-alpha01
* Version of Gradle: 6.2.2
* Version of Java: 8
* OS: MacOS 10.15.3 (19D76)
When using the `Table` composable, any `tableDecoration`s are not drawn in the Android Studio preview, but they're drawn on devices and emulators.
E.g.:
```kotlin
@Preview @Composable fun ReproTableBug() {
Box(DrawBackground(color = Color.White)) {
Table(columns = 2) {
tableDecoration(overlay = false) {
Box(shape = CircleShape, backgroundColor = Color.Red)
}
tableRow {
Text("1")
Text("2")
}
tableRow {
Text("3")
Text("4")
}
}
}
}
```
I've attached two screenshots. Notice the lack of any red circle in the one from Android Studio.