Reworl the splash screen part 1 & 2 #20157

TurboGit · 2026-01-14T17:54:48Z

Rename all routines from darktable_ prefix to dt_ to conform to style.
Never force the splash screen. We are then loosing the crawler messages but this could create a race condition. We create the splash in a different threads than the main one. This is wrong as the creation of the splash screen is not protected against concurrent access.
Remove all static routines and move the needed variable into darktable struct (dt_splash_t).
Do not use a dialog but instead a simple top level window.
Remove code for the exit window. Not activated/implemented and if we need to implement this we can recover the code from history.

jenshannoschwalm · 2026-01-14T18:58:05Z

Yes, not starting in another thread is for sure good!

gi-man · 2026-01-14T23:10:47Z

I built this PR on Windows 11. Dt crashes when I disable the splash screen.

TurboGit · 2026-01-15T07:03:25Z

@gi-man : And you do not see very briefly the splash screen anymore, right?

Are you willing to debug this with me? If I instrument the code, would you be able to compile, run and report what you see?

dterrahe · 2026-01-15T08:48:44Z

We create the splash in a different threads than the main one.

Where? I only see it in dt_init which is in the main/gui thread, no? The crawler is also run there, so all the progress percentage updates should be gui thread too?

TurboGit · 2026-01-15T08:56:21Z

Where? I only see it in dt_init which is in the main/gui thread, no? The crawler is also run there, so all the progress percentage updates should be gui thread too?

It is removed from this PR. The creation was done on the main treads (my message was incorrect on this) but then multiple threads (if you include the crawler) where updating the splash with messages.

dterrahe · 2026-01-15T09:05:54Z

Like I said, dt_control_crawler_run is also called from dt_init so it is running in the gui thread (which is waiting for its completion). So again, which other threads are updating the splash with messages? Simply asking because that would also be a problem when the splash screen is not disabled.

TurboGit · 2026-01-15T09:23:28Z

@dterrahe : Indeed, missed that, I really thought that the crawler was in an independent thread. That explain why this PR did not fix the issue. Back to debug...

gi-man · 2026-01-15T10:33:21Z

@gi-man : And you do not see very briefly the splash screen anymore, right?

Are you willing to debug this with me? If I instrument the code, would you be able to compile, run and report what you see?

The screen showing up is on Fedora KDE current master. On Windows it initially just has the terminal, then dt window shows up with the tittle bar (the one with the X to close or minimize) with a white background. It will remain like this until I close/stop the process.

I'm willing to debug. I am 6hrs behind you so there will be a delay. Yes, I can compile and run it on Windows.

TurboGit · 2026-01-15T10:39:18Z

@gi-man : Perfect ! I have just push a new version I had prepared.

The goal is to run darktable from command line with SPLASH_DEBUG set to some value and report if it work or not and the output in the console.

First, set SPLASH_DEBUG=15 and test (this makes the splash screen a no-op), it should pass, if not we can stop here.
set SPLASH_DEBUG=2
set SPLASH_DEBUG=4
set SPLASH_DEBUG=1
set SPLASH=DEBUG=8

And we'll advise for the next step. Thanks for your help!

TurboGit · 2026-01-15T12:11:17Z

Last but not least, do you have Lua scripts? If so, can you disable Lua completely (remove the luarc file).

gi-man · 2026-01-15T14:12:27Z

version: darktable 5.5.0+97~g53f7316e96
start: 2026-01-15 09:09:52

     0.0001 [dt starting]
 darktable.exe SPLASH_DEBUG=15 --configdir C:\msys64\opt\test --cachedir C:\msys64\opt\test
[dt_splash_screen_create] (force:0) (0)
   no create (conf)
[dt_splash_screen_set_progress] (opening image library)
   not initialized
[dt_splash_screen_set_progress] (preparing database)
   not initialized
[dt_splash_screen_set_progress] (setting up tags table)
   not initialized
[dt_splash_screen_set_progress] (initializing signals and control)
   not initialized
[dt_splash_screen_set_progress] (importing default styles)
   not initialized
[dt_splash_screen_set_progress] (initializing GraphicsMagick)
   not initialized
[dt_splash_screen_set_progress] (initializing libheif)
   not initialized
[dt_splash_screen_set_progress] (starting OpenCL)
   not initialized
[dt_splash_screen_set_progress] (loading noise profiles)
   not initialized
[dt_splash_screen_set_progress] (synchronizing local copies)
   not initialized
[dt_splash_screen_set_progress] (initializing camera control)
   not initialized
[dt_splash_screen_set_progress] (initializing GUI)
   not initialized
[dt_splash_screen_set_progress] (loading processing modules)
   not initialized
[dt_splash_screen_set_progress] (loading utility modules)
   not initialized
[dt_splash_screen_set_progress] (loading views)
   not initialized
[dt_splash_screen_set_progress] (initializing Lua)
   not initialized
[dt_splash_screen_destroy] (0)
   not initialized

I have to drive into work today. I will continue to test in the evening.

gi-man · 2026-01-15T14:18:58Z

For clarity it did crash. I just did another run using -d all to see if it provides more insights.

[dt_splash_screen_set_progress] (loading views)
   not initialized
[dt_splash_screen_set_progress] (initializing Lua)
   not initialized
     2.5586 [undo] clear list for 2047 (length 0)
     2.5586 [undo] clear list for 2047 (length 0)
     2.5751 [add_job]	00  generate mipmaps | queue: DT_JOB_QUEUE_SYSTEM_BG | priority: 0
     2.5752 [run_job+]	06  generate mipmaps | queue: DT_JOB_QUEUE_SYSTEM_BG | priority: 0
     2.5752 [undo] clear list for 2041 (length 0)
     2.5752 [undo] clear list for 2041 (length 0)
     2.5752 [thumb crawler] closing due to preferences setting
     2.5752 [sql] C:/msys64/home/gman/darktable/src/common/collection.c:907, function dt_collection_get_selected_count(): prepare "SELECT COUNT(*) FROM main.selected_images"
     2.5752 [run_job-]	06  generate mipmaps | queue: DT_JOB_QUEUE_SYSTEM_BG | priority: 0
     2.5754 [sql] C:/msys64/home/gman/darktable/src/common/collection.c:941, function dt_collection_get(): prepare "SELECT mi.imgid FROM main.selected_images AS s JOIN memory.collected_images AS mi WHERE mi.imgid = s.imgid LIMIT -1, ?1"
     2.5755 [sql] C:/msys64/home/gman/darktable/src/common/collection.c:2797, function dt_collection_image_offset_with_collection(): prepare "SELECT imgid FROM memory.collected_images"
     2.5779 [add_job]	00  synchronize sidecars | queue: DT_JOB_QUEUE_SYSTEM_FG | priority: 0
     2.5779 [run_job+]	09  synchronize sidecars | queue: DT_JOB_QUEUE_SYSTEM_FG | priority: 4
     2.8340 [dt_get_system_gui_ppd] system ppd is 1.000000
     2.8340 [screen resolution] setting the screen resolution to 120.000000 dpi 
[dt_splash_screen_destroy] (0)
   not initialized
     2.8495 [dt_init] startup took 2.849481 seconds
     2.8495 [memory] after successful startup
            max address space (vmpeak):       449796 kB
            cur address space (vmsize):       449796 kB
            max used memory   (vmhwm ):       273248 kB
            cur used memory   (vmrss ):       273248 Kb
     4.3826 [camera_control] loaded 0 port drivers
     4.3827 [camera_control] 0 cameras connected

TurboGit · 2026-01-15T14:25:34Z

To run it should be on a standard Windows console:

c> set SPLASH_DEBUG=15
c> darktable ...

Sorry for not having been clear.

gi-man · 2026-01-15T21:25:24Z

To run it should be on a standard Windows console:
c> set SPLASH_DEBUG=15
c> darktable ...
Sorry for not having been clear.

version: darktable 5.5.0+97~g53f7316e96
start: 2026-01-15 16:23:34

 0.0001 [dt starting]

darktable.exe --configdir C:\msys64\opt\test --cachedir C:\msys64\opt\test
[dt_splash_screen_create] (force:0) (0)
reset
[dt_splash_screen_set_progress] (opening image library)
[dt_splash_screen_set_progress] (preparing database)
[dt_splash_screen_set_progress] (setting up tags table)
[dt_splash_screen_set_progress] (initializing signals and control)
[dt_splash_screen_set_progress] (importing default styles)
[dt_splash_screen_set_progress] (initializing GraphicsMagick)
[dt_splash_screen_set_progress] (initializing libheif)
[dt_splash_screen_set_progress] (starting OpenCL)
[dt_splash_screen_set_progress] (loading noise profiles)
[dt_splash_screen_set_progress] (synchronizing local copies)
[dt_splash_screen_set_progress] (initializing camera control)
[dt_splash_screen_set_progress] (initializing GUI)
[dt_splash_screen_set_progress] (loading processing modules)
[dt_splash_screen_set_progress] (loading utility modules)
[dt_splash_screen_set_progress] (loading views)
[dt_splash_screen_set_progress] (initializing Lua)
[dt_splash_screen_destroy] (0)

TurboGit · 2026-01-15T21:46:04Z

So not crash here, right?

TurboGit · 2026-01-15T21:47:24Z

If no crash, now let's set SPLASH_DEBUG to other values and report if it crashes or not and the actual log. TIA.

gi-man · 2026-01-15T21:48:21Z

So not crash here, right?

It did crash with SPLASH_DEBUG=15

gi-man · 2026-01-15T21:50:45Z

As an experiment I tried, even with the show_splash_screen=TRUE, it crashes with any value in SPLASH_DEBUG!=0.

If I set SPLASH_DEBUG=0 and show_splash_screen=TRUE, then no crash.

TurboGit · 2026-01-15T21:55:29Z

It did crash with SPLASH_DEBUG=15

This means that the issue is not really the splash screen as with value 15 the splash screen is a no-op. Only a printf to display some information and that's all. No dialog created, no widget created, no manual handling of events...

If I set SPLASH_DEBUG=0 and show_splash_screen=TRUE, then no crash.

Ok, that's then basically the current code on master.

As an experiment I tried, even with the show_splash_screen=TRUE, it crashes with any value in SPLASH_DEBUG!=0.

Even for value 2? as this only reset to NULL a widget that should be null anyway.

gi-man · 2026-01-15T21:59:43Z

show_splash_screen, SPLASH_DEBUG, Crash?
1, 0, No crash
0, 0, Crash
1, 15, Crash
0, 15, Crash
0, 8, Crash
1, 8, No crash and splash screen shows when closing dt
1, 1, Crash
1, 4, No crash
1, 2, No crash
1, 1, Crash (I repeated to confirm)

TurboGit · 2026-01-15T22:01:07Z

What about 0,2 ?

gi-man · 2026-01-15T22:04:52Z

0, 2, Crash
0, 4, Crash
0, 8, Crash

TurboGit · 2026-01-15T22:05:41Z

Ok, all this seems to indicate a memory corruption, but not something directly related to the splash screen.

Are you able to use the gdb debugger?

TurboGit · 2026-01-16T07:06:01Z

I managed to get it to run in gdb. It does not crash.

I see, if you could find a combination where it crashes and get a backtrace it would be nice.

Again, the fact that it does not crashes on gdb but crash on the same condition without gdb really favor a memory corruption or possibly a race condition.

TurboGit · 2026-01-16T07:49:07Z

Something else to test is to build without Lua. I have found some comments in the code saying that we had issues...

Be sure to clean completely the build directory:

> rm -fr build

And build without Lua:

> ./build.sh --disable-lua

I let you adapt the command for Windows.

gi-man · 2026-01-16T14:05:01Z

I'm using --clean-all in the build.sh

Since it is not crashing in gdb (dt works but very slow), I decided to start bisection approach. It takes a while on windows to do the builds. I'm at this commit from 27Sep and it crashes here 1dbb8b6 We know it doesnt crash at 5.2.1. I'm at home today, so I should be able to find the commit.

TurboGit · 2026-01-16T14:43:34Z

@gi-man : Thanks! It will be a very big progress.

gi-man · 2026-01-16T15:42:55Z

I'm currently here.

1c11e84 - No crash 07Aug2025

15d4c0a - Crash 14Aug2025

f29de89 - Crash 21Aug2025

TurboGit · 2026-01-16T15:51:00Z

Let's bet on the changes in src/views/view.c... just for fun :) Keep going!

dterrahe · 2026-01-16T16:03:54Z

You are suggesting 1270eac could be improved by checking that the old view is not null (i.e. that this is not the initial change to lighttable, which happens before we've started the event loop)?

TurboGit · 2026-01-16T16:08:52Z

No, 1270eac in not inside [1c11e84..15d4c0a] (between 7 & 14 Aug).

dterrahe · 2026-01-16T16:30:03Z

But f8281cc is? 1270eac was an earlier (but now it seems incomplete) attempt to fix problems that caused.

Hard to check here on the Android app; it doesn't show dates for commits, just "5mo" ago.

TurboGit · 2026-01-16T16:33:53Z

Yes, I suspect f8281cc, why? Because the other changes seems ok. But @dterrahe that's just a bet guess :) Nothing serious, let's wait @gi-man final bisect.

dterrahe · 2026-01-16T16:38:54Z

And then if it is, he could try changing

if(new_view != old_view)

to

if(old_view && new_view != old_view)

and see if that helps.

gi-man · 2026-01-16T16:41:39Z

Sorry, I had to present in a meeting. Yeah, that f8281 has to be it. I'm building it now (windows is slow to compile) to confirm.

1c11e84 - No crash 07Aug2025

16d6695 - No crash 12Aug2025

5e965db - No crash 14Aug2025

f8281cc - This has to be it building

15d4c0a - Crash 14Aug2025

f29de89 - Crash 21Aug2025

gi-man · 2026-01-16T16:55:40Z

Yes, f8281cc is when we start to crash.

TurboGit · 2026-01-16T16:58:33Z

Congrats! And a big thanks for your time.

Let's try @dterrahe proposal now...

You can move on commit: 1270eac

And change the check:

if(new_view != old_view)

to

if(old_view && new_view != old_view)

Thanks.

gi-man · 2026-01-16T17:53:16Z

Lunch was good. This change if(old_view && new_view != old_view) worked on top of 1270eac

jenshannoschwalm · 2026-01-16T19:37:05Z

This change if(old_view && new_view != old_view) worked on top of 1270eac

Do i understand this correctly, this does not make dt crash or hanging?

BTW while being here,

in the crawler we call darktable_splash_screen_set_progress_percent(), is that correctly done this way? Wouldn't we have to call it via g_main_context_invoke() instead - or for what work would we have to do so?
Is there any specific reason we do the crawler as we do it now instead of a cancelable job?

gi-man · 2026-01-16T19:50:44Z

Do i understand this correctly, this does not make dt crash or hanging?

Correct. Changing view.c line 310 as suggested by @dterrahe resolves the crashes on windows dt.

dterrahe · 2026-01-17T08:30:23Z

It seems that just gdk_display_sync(gdk_display_get_default()) is sufficient to update the cursor in view.c, without processing the main loop. At least from very brief testing just on wayland.

Could someone do more extensive testing after replacing

  if(new_view != old_view)
     dt_gui_process_events();

with

  gdk_display_sync(gdk_display_get_default());

The thing to test, under x11/windows/mac, is if double clicking on an image in the lighttable still immediately shows the "waiting" cursor while the image is being loaded.

TurboGit · 2026-01-17T08:41:35Z

@dterrahe : I'd like to go safe and simple for 5.4.1, so I'll fix the line as you've proposed in your first message. The change with gdk_display_sync(gdk_display_get_default()); will need more (field) testing I think.

TurboGit · 2026-01-17T08:53:43Z

Moving this for 5.6 now that we have a fix for 5.4.1. The goal here is to clean-up splash screen by avoid the static variables and to avoid the crawler to splash a screen even if there is no message to be displayed.

TurboGit · 2026-01-17T08:54:31Z

@gi-man : Thanks for the hard work, please do not hesitate to test tomorrow nightly build to ensure all is back to normal.

dterrahe · 2026-01-17T18:48:57Z

I may have found the reason why darktable_splash_screen_set_progress would hang if called after dt_lua_init. I've incorporated a fix into #20161. This now enables darktable_splash_screen_set_progress(_("importing image")); even when USE_LUA (where previously this would quite consistently get stuck). The synchronisation pattern used in gtk_wrap seems to have been implemented slightly incorrectly from the start. It is not impossible that this also could cause problems elsewhere, but less consistently than at startup. If after extensive testing (on all platforms) it is confirmed that this is indeed a fix, it might be worth searching in the code if there are workarounds in place to avoid similar crashes involving lua elsewhere and that might now be safely removed.

@ralfbrown @wpferguson

- Rename all routines from darktable_ prefix to dt_ to conform to style. - Never force the splash screen. We are then loosing the crawler messages but this could create a race condition. We create the splash in a different threads than the main one. This is wrong as the creation of the splash screen is not protected against concurrent access.

Remove all static routines and move the needed variable into darktable struct (dt_splash_t). Do not use a dialog but instead a simple top level window. Remove code for the exit window. Not activated/implemented and if we need to implement this we can recover the code from history.

gi-man · 2026-01-19T03:43:04Z

@gi-man : Thanks for the hard work, please do not hesitate to test tomorrow nightly build to ensure all is back to normal.

I was just able to test after a busy weekend. Current master works without issues.

TurboGit added this to the 5.4.1 milestone Jan 14, 2026

TurboGit added bugfix pull request fixing a bug priority: high core features are broken and not usable at all, software crashes scope: UI user interface and interactions release notes: pending labels Jan 14, 2026

TurboGit requested a review from jenshannoschwalm January 14, 2026 17:55

TurboGit force-pushed the po/splash-rework branch from f7837cd to 53f7316 Compare January 15, 2026 10:35

gi-man mentioned this pull request Jan 16, 2026

darktable 5.4.0 fails to start fully on unknown condition #19992

Closed

1 task

TurboGit modified the milestones: 5.4.1, 5.6 Jan 17, 2026

TurboGit added 2 commits January 17, 2026 22:10

TurboGit force-pushed the po/splash-rework branch from 53f7316 to 03dc648 Compare January 17, 2026 21:24

TurboGit changed the title ~~Attempt to fix the splash screen issue.~~ Reworl the splash screen part 1 & 2 Jan 17, 2026

Reworl the splash screen part 1 & 2 #20157

Are you sure you want to change the base?

Reworl the splash screen part 1 & 2 #20157

Conversation

TurboGit commented Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jenshannoschwalm commented Jan 14, 2026

Uh oh!

gi-man commented Jan 14, 2026

Uh oh!

TurboGit commented Jan 15, 2026

Uh oh!

dterrahe commented Jan 15, 2026

Uh oh!

TurboGit commented Jan 15, 2026

Uh oh!

dterrahe commented Jan 15, 2026

Uh oh!

TurboGit commented Jan 15, 2026

Uh oh!

gi-man commented Jan 15, 2026

Uh oh!

TurboGit commented Jan 15, 2026

Uh oh!

TurboGit commented Jan 15, 2026

Uh oh!

gi-man commented Jan 15, 2026

Uh oh!

gi-man commented Jan 15, 2026

Uh oh!

TurboGit commented Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gi-man commented Jan 15, 2026

Uh oh!

TurboGit commented Jan 15, 2026

Uh oh!

TurboGit commented Jan 15, 2026

Uh oh!

gi-man commented Jan 15, 2026

Uh oh!

gi-man commented Jan 15, 2026

Uh oh!

TurboGit commented Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gi-man commented Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TurboGit commented Jan 15, 2026

Uh oh!

gi-man commented Jan 15, 2026

Uh oh!

TurboGit commented Jan 15, 2026

Uh oh!

TurboGit commented Jan 16, 2026

Uh oh!

TurboGit commented Jan 16, 2026

Uh oh!

gi-man commented Jan 16, 2026

Uh oh!

TurboGit commented Jan 16, 2026

Uh oh!

gi-man commented Jan 16, 2026

Uh oh!

TurboGit commented Jan 16, 2026

Uh oh!

dterrahe commented Jan 16, 2026

Uh oh!

TurboGit commented Jan 16, 2026

Uh oh!

dterrahe commented Jan 16, 2026

Uh oh!

TurboGit commented Jan 16, 2026

Uh oh!

dterrahe commented Jan 16, 2026

Uh oh!

gi-man commented Jan 16, 2026

Uh oh!

TurboGit commented Jan 14, 2026 •

edited

Loading

TurboGit commented Jan 15, 2026 •

edited

Loading

TurboGit commented Jan 15, 2026 •

edited

Loading

gi-man commented Jan 15, 2026 •

edited

Loading