[SOLVED] Skiko RenderException: Cannot create OpenGL context

seth · 2026-06-24 21:47:05

Could they explain why the engine is looping when you tell it to use the raster (or software) API?
Does exporting LIBGL_ALWAYS_SOFTWARE=1 help?

astroboy · 2026-07-03 11:34:50

JetBrains helped me solve the problem! I actually thought they would send me to Arch Linux Forums becuase the issue is somehow related to the system update I did, so that's why I asked here first, but turns out the more correct place would be their YouTrack.

The YouTrack thread was made private btw, but I will tell the story here shortly. And what helped me solve the problem.

PyCharm magically fixed itself, I don't know how. But Android Studio still had the problem. They asked me for some logs:

Good catch on the openbox retest, and no worries about the earlier mix-up. It actually helps: if the hang happens under both Cinnamon and openbox, the desktop environment is not the cause. Combined with it starting right after a system update, the likely trigger is something in your graphics stack (Mesa, the AMD driver, or the kernel) rather than the IDE itself.
To pin down where it spins and what changed, could you collect a few things?
1. A thread dump while it is hung (this is the most useful one). Launch PyCharm from a terminal, and once it freezes with the CPU spinning, run this from another terminal a few times, a few seconds apart:
jps # find the PyCharm PID
jstack <pid> > skiko-hang-1.txt
This shows whether it is still spinning in Skiko's render-API selection even with the SOFTWARE renderer forced.

These are the commands I ran:

 ~ > jps    
31076 Jps
30821 MainWrapper
25403 GradleDaemon
 ~ > jstack 30821 > skiko-before-hang-1.txt                  
 ~ > jstack 30821 > skiko-hang-1.txt       
 ~ > jstack 30821 > skiko-hang-2.txt
 ~ > jstack 30821 > skiko-hang-3.txt
 ~ > jstack 30821 > skiko-hang-4.txt
 ~ > jstack 30821 > skiko-hang-5.txt

They found the issue in the logs:

What the dumps show
All five skiko-hang-*.txt dumps have the EDT in the same place:
"AWT-EventQueue-0"  RUNNABLE
  org.jetbrains.skia.FontMgrKt._nDefault(Native Method)
  org.jetbrains.skia.FontMgr.<clinit>
  androidx.compose.ui.text.platform.FontCache.<init>
  androidx.compose.ui.text.font.SkiaFontLoader.<init>
  androidx.compose.ui.text.font.FontFamilyResolver_sikioKt.createFontFamilyResolver
  androidx.compose.ui.node.RootNodeOwner$OwnerImpl.<init>
  androidx.compose.ui.scene.CanvasLayersComposeSceneImpl.<init>
  androidx.compose.ui.scene.ComposeContainer.createComposeScene
  ...
  com.intellij.openapi.ui.impl.DialogWrapperPeerImpl.show
  com.android.tools.idea.npw.actions.AndroidNewProjectAction.actionPerformed
EDT CPU time grows roughly one-for-one with elapsed wall time across the five snapshots (6.4 s → 14.3 s → 18.5 s → 24.4 s → 32.1 s over about 26 s of wall clock). That means the EDT is spinning in native code, not blocked on a lock. The pre-click baseline (skiko-before-hang-1.txt) shows the EDT idle (WAITING), so the click into "New project" is what kicks it into this state.
What this means
The hang is inside the Skia FontMgr static initializer, before any renderer is selected. On Linux, Skia's default font manager is backed by fontconfig, so _nDefault() is calling into FcInit / FcConfigParseAndLoad and the system font enumeration. That call is taking 30+ seconds of CPU on your machine.
This is why -Dskiko.renderApi=SOFTWARE did not clear the hang: it changes the GPU pipeline, but font manager init runs upstream of that. It is also why the related issues we discussed earlier (IJPL-247209, IJPL-188392) do not apply here, those are renderer-fallback bugs.
Worth trying on your side
This usually points at a slow or broken fontconfig state. The fastest thing to test:
# 1) Rebuild the fontconfig cache from scratch
rm -rf ~/.cache/fontconfig
fc-cache -f -r -v
# Watch the output for lines containing "error" or "broken",
# or any single directory that takes many seconds to scan.
# 2) Baseline native font lookup speed
time fc-match sans-serif
time fc-list | wc -l
If fc-cache itself hangs or fc-match is multi-second, that confirms the issue is in the system fontconfig setup, independent of Android Studio. In that case, look for an unusually large user font tree under ~/.local/share/fonts or ~/.fonts, or a malformed font file in one of the scanned directories. Temporarily moving those folders aside and relaunching Android Studio is a quick way to bisect.
Platform side
There is a separate platform issue we are tracking where native Compose initialization, including font manager setup, runs on the EDT for the first ComposePanel. Moving that work off the EDT would not make fontconfig faster, but it would stop the UI from freezing while it happens. I will link your report against that issue internally.
For longer-term context on Skiko on Linux, the upstream work is SKIKO-1138 (Vulkan renderer for Skiko on Linux), though that is renderer-side and not directly related to the font init slowdown.
Please share the output of fc-cache -f -r -v and time fc-match sans-serif when you get a chance, that will tell us whether the slowness is in the cache build or in the runtime match.

And that was it, rebuilding the cache fixed all my problems. Both Android Studio and my apps are working now. They even published a knowledge article about it https://youtrack.jetbrains.com/articles … x-Cinnamon

seth · 2026-07-03 13:35:54

so one more for https://bbs.archlinux.org/viewtopic.php?id=313799
Thanks for the heads up.

Arch Linux

#26 2026-06-24 21:47:05

Re: [SOLVED] Skiko RenderException: Cannot create OpenGL context

#27 2026-07-03 11:34:50

Re: [SOLVED] Skiko RenderException: Cannot create OpenGL context

#28 2026-07-03 13:35:54

Re: [SOLVED] Skiko RenderException: Cannot create OpenGL context

Board footer