I'm running into a strange problem while implement...

# compose-desktop

[Sebastian Kürten]

I'm running into a strange problem while implementing a drawer in Compose, but only on one Windows 10 machine. I have created a small example repo with this main function. The video below illustrates how things are supposed to look as expected on a Linux box. The red drawer on the left is always visible (its purpose is width comparison with the other one). The cyan drawer on the right can be toggled using the button. The size of both drawers can be adjusted using the slider to illustrate the problem on the Windows box.

screencast.webm

[Sebastian Kürten]

On the Windows 10 machine, everything looks good when the drawer is expanded:

[Sebastian Kürten]

resizing also works:

[Sebastian Kürten]

but when I toggle the drawer, it doesn't get hidden entirely:

[Sebastian Kürten]

Screenshot__31_.png

[Sebastian Kürten]

the effect is more extreme the larger I make the drawer:

[Sebastian Kürten]

Screenshot__32_.png

[Sebastian Kürten]

Screenshot__33_.png

[Sebastian Kürten]

This is the code for that is responsible for the drawer:

Surface(
                modifier = Modifier
                    .fillMaxHeight()
                    .requiredWidth(width.value.dp)
                    .align(Alignment.CenterEnd)
                    .offset { IntOffset(if (enabled.value) 0 else width.value, 0) },
                color = Color.Cyan.copy(alpha = 0.5f)
            ) {

            }

[Sebastian Kürten]

As said, it works just fine on various Linux boxes, as well as a Windows 11 box and a bunch of Windows 10 virtual boxes. On the problematic Win 10 box, I have tried a bunch of different Compose versions, including 1.1.1, 1.2.0, 1.2.1, 1.2.2 and 1.3.0-rc02; all with the same result

[Sebastian Kürten]

I would be curious if
• anybody else can reproduce the problem (it's quick to try: check out the repository mentioned above and just run the example either using ./gradlew run or from IntelliJ or Android Studio),
• anybody got an idea what the root problem could be or has an idea how to debug this further.

[Sebastian Kürten]

btw. I can "fix" this by increasing the offset by a factor of 1.25:
.offset { IntOffset(if (enabled.value) 0 else (width.value * 1.25f).roundToInt(), 0) },
Of course this is not a good solution, but maybe that factor rings a bell? 1.2 is not enough yet, but 1.25 seems to be the exact right amount....

[Kirill Grouchnikov]

Might be related to how you treat width.value interchangeably as sometimes pixels and sometimes dp. Are these boxes on different screens with different densities / DPI?

[Sebastian Kürten]

thanks, good hint. Maybe the density is 1.25 on that particular box, I'll have to check. Hmm, IntOffset only accepts integers, so probably something like this: `

.offset { IntOffset(if (enabled.value) 0 else width.value.dp.roundToPx(), 0) },

could help I guess...

[Sebastian Kürten]

Thanks @Kirill Grouchnikov that was it. LocalDensity is 1.25 indeed and using the .dp.roundToPx() fixes the issue!