Rework 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?

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.

dterrahe · 2026-01-20T07:45:41Z

The splash screen is only used in dt_init (and, from there, in dt_control_crawler_run). It wouldn't make sense to access it at any point after init is finished. So why not make dt_splash_t splash a local variable in dt_init (and pass it to dt_control_crawler_run) instead of having it as a "global" variable in darktable?

TurboGit · 2026-01-20T08:31:14Z

Good point @dterrahe, I had also in mind to add more to the splash screen like the name of all modules (iop and libs) loaded (as done in GIMP). That would mean passing dt_splast_t to more routines.

dterrahe · 2026-01-20T08:43:58Z

It would be nice to then also have a percentage progress indicator, but that quickly becomes tricky, because the generic dt_module_load_modules doesn't look up front how many module files there are and it is not aware of the internal (translated) names, just the file names. So on the face of it this would require a lot of restructuring. And most likely you'd then get a messsage after each module was loaded (so you can get the name) rather than before it happens (so you know the culprit if you get stuck).

dterrahe · 2026-01-20T09:06:07Z

You could extend dt_module_load_modules a little, starting with while((dir_name = g_dir_read_name(dir)))

  const double start_time = dt_get_wtime();
  int num_modules = 0, current_module = 0;
  while(g_dir_read_name(dir)) num_modules++;
  g_dir_rewind(dir);
  while((dir_name = g_dir_read_name(dir)))
  {
    current_module++;
    // get lib*.so
    if(!g_str_has_prefix(dir_name, SHARED_MODULE_PREFIX))
      continue;
    if(!g_str_has_suffix(dir_name, SHARED_MODULE_SUFFIX))
      continue;
    char *plugin_name = g_strndup(dir_name + name_offset, strlen(dir_name) - name_end);
    void *module = calloc(1, module_size);
    gchar *libname = g_module_build_path(plugindir, plugin_name);
    gchar *msg = g_strdup_printf(_("loading module %s (%%d%%%%)"), libname);
    darktable_splash_screen_set_progress_percent(msg,
                                                 (double)current_module / (double)num_modules,
                                                 dt_get_wtime() - start_time);
    g_free(msg);

(you'd need to include gui/splash.h and common/darktable.h)
It would make sense to put the additional info in set_progress_percent on a separate line instead of overwriting the main progress message.

TurboGit · 2026-01-20T18:29:44Z

A minor addition (no progress, the display is so fast anyway...). We now see the loading iop & utility module.

src/develop/imageop.c

Also add the loading information into the verbose debug output.

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

TurboGit changed the title ~~Reworl the splash screen part 1 & 2~~ Rework the splash screen part 1 & 2 Jan 20, 2026

dterrahe reviewed Jan 20, 2026

View reviewed changes

src/develop/imageop.c Show resolved Hide resolved

TurboGit force-pushed the po/splash-rework branch from a79d295 to 73616ef Compare January 20, 2026 22:08

Add utility and processing modules in splash screen.

fffdbf1

Also add the loading information into the verbose debug output.

TurboGit force-pushed the po/splash-rework branch from 73616ef to fffdbf1 Compare January 20, 2026 22:25

Rework the splash screen part 1 & 2 #20157

Are you sure you want to change the base?

Rework 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!

dterrahe commented Jan 16, 2026

Uh oh!

gi-man 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!

jenshannoschwalm commented Jan 16, 2026

Uh oh!

gi-man commented Jan 16, 2026

Uh oh!

dterrahe commented Jan 17, 2026

Uh oh!

TurboGit commented Jan 17, 2026

Uh oh!

TurboGit commented Jan 17, 2026

Uh oh!

TurboGit commented Jan 17, 2026

Uh oh!

dterrahe commented Jan 17, 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