Hi there! I'm currently writing an intellij plugin...
# jewel
l
Hi there! I'm currently writing an intellij plugin that has a custom file editor, and while trying to figure out how to use compose for rendering it, I stumbled upon jewel. My editor is more or less a big form, and I want to standardize the "shape" of the form across intellij and some other editors I want to support, so compose is perfect for my use case. The rendering itself works perfectly, and everything shows up as expected, however there is a pretty noticeable delay in opening the editor for the first time, and for subsequent opens the delay is still pretty big. I did some profiling, and apparently most of the time is spent attaching the
JComponent
returned from
FileEditor::getComponent
to the component of the editor tab. Compose seems to do some pretty heavy initialization when
addNotify
is called, and almost 500ms is spent on
androidx.compose.ui.awt.ComposePanel#createComposeContainer
. 180ms on
createDirectXOffscreenDevice
(I'm on windows). The next time I switch to the editor it takes about 100ms. Other file editors open much quicker. I also implemented a simple button incrementing a counter in compose, which (after it was displayed) was responsive as expected. So it's just something about (re-)attaching the component. Before I invest more time into this, I just wanted to confirm if this is expected/known, and if something like a file editor (which is recreated quite often) is even supposed to be supported by jewel? If its something that is expected to improve over time, I can live with the loading time, but if this is not really going to be a supported use case, I can probably save me a lot of future headaches by implementing another solution now 😄 For reference, this is what I'm doing:
Copy code
class MyFileEditor(private val file: VirtualFile) : NavigatableFileEditor, UserDataHolderBase() {
    init {
        enableNewSwingCompositing()
    }

    private val panel = JewelComposePanel { Text("Hello World") }

    override fun getComponent(): JComponent {
        return panel
    }

    override fun getPreferredFocusedComponent(): JComponent? {
        return panel
    }

    // The rest is standard file editor boilerplate, just enough to get it to display...
}
s
Hi there! These perf issues are not related to Jewel — which is a theme and set of components — but seem rather to be a CMP issue. Would be great if you could file an issue on YouTrack with minimal repro steps, so we can ask them to look into it
Jewel doesn't explicitly support or not support specific use cases, to your question. It's just in the current Compose Multiplatform implementation for Desktop, there are limitations that make using Compose more or less sense depending on what you're trying to do with ite
Using Compose for large surfaces at the moment comes with some perf penalties due to the need to copy back and forth GPU -> CPU -> GPU when compositing (web content suffers the same issues in the IDE). Obviously the larger the surface, the larger the buffer to copy is. It only copies when stuff recomposes, so in many cases it's ok, but it can get bad. Work is undergoing to solve this, but it'll take time.
l
Hi! Thanks for the detailed response, that makes sense. I wasn't quite sure where the line is between what jewel does, what compose does, and what IntelliJ does, etc. I'll experiment with some other ideas I had, then I can probably still use all the components from jewel 🙂
🦜 1