GTK + gtk_widget_show_all () takes a lot of time after fork and exec ()

I am developing a GTK+ application for Linux that runs from another GTK+ application using fork() and then execvp() .

What I notice is that the exec () 'd application takes about 10-15 seconds to complete the call to gtk_widget_show_all() . After this period, widgets and a window appear, and the application works fine.

So, the application call looks like this:

main_gtk_ app → fork () → execvp (secondary_gtk_app). secondary_gtk_app takes a long time to display a window and widgets.

However, if I run the application directly and not exec () 'd from the GTK + application, there is no delay in the gtk_widget_show_all() call from the command line.

Vocation:

shell command line: ./ secondary_gtk_app (start from the command line, no delay in displaying windows and widgets).

Does anyone know what might cause this behavior? Or a way to reduce the time spent on gtk_widget_show_all() ?

EDIT: after some research, it seems that most of the delay is related to GTK +, which does some font initialization. If I run fc-cache -f , which creates font caches for the Fontconfig system on the embedded device before starting work, secondary_gtk_app loads in about 2 seconds. Therefore, it is associated with the processing of fonts.

+4
source share
1 answer

In general, Gtk applications are not recommended to do fork() , but use the g_spawn_* family of functions g_spawn_* .

Of course, you can call fork() if you really need or need, but you need to take care of at least one important point: close all file descriptors to call exec*() . If you do not, the child process will inherit many (all) of the original fds.

Note that the graphics application has at least one fd connecting it to the X11 server. And perhaps even more ...

For more detailed information that you will ever want to know, you can see the source of the g_spawn_*() functions.

+1
source

Source: https://habr.com/ru/post/1433433/


All Articles