gtk: why codegen when you can embed #8539
Conversation
When you do `glib-compile-resources` with `--generate-header` or `--generate-source`, it generates really long and stinky C source files littered with lengthy escape codes, macros and compiler directives, just because C doesn't (yet!) have a standard way to just embed a file as a literal bunch of bytes. However, we do have access to that in Zig. So why not just do the same thing but better?
There was a problem hiding this comment.
Since this is part of the startup path, I’d be curious how much slower it is to load them via bytes like this versus compiling the C files which presumably stores them in some ready format? (I’m not actually sure what they do)
If this affects startup time it’s probably not worth it.
|
The C file is essentially a big byte array plus some shims to make it work with the gio.Resource API. More specifically they're kind of using a hack (gio.StaticResource) so that you don't have to go through glib.Bytes, but given this is only ever called once I don't think this will change anything |
|
More specifically it looks like this: #include <gio/gio.h>
#if defined (__ELF__) && ( __GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 6))
# define SECTION __attribute__ ((section (".gresource.ghostty"), aligned (sizeof(void *) > 8 ? sizeof(void *) : 8)))
#else
# define SECTION
#endif
static const SECTION union { const guint8 data[1805701]; const double alignment; void * const ptr;} ghostty_resource_data = {
"\107\126\141\162\151\141\156\164\000\000\000\000\000\000\000\000"
/* A LOT OF RAW STRING LITERALS */
};
static GStaticResource static_resource = { ghostty_resource_data.data, sizeof (ghostty_resource_data.data) - 1 /* nul terminator */, NULL, NULL, NULL };
G_MODULE_EXPORT
GResource *ghostty_get_resource (void);
GResource *ghostty_get_resource (void)
{
return g_static_resource_get_resource (&static_resource);
} |
|
I’d like to measure this before merging to be sure. It may be a hack but it’s not our hack, it’s an official hack even so I don’t mind it. Startup time matters. |
When you do
glib-compile-resourceswith--generate-headeror--generate-source, it generates really long and stinky C source files littered with lengthy escape codes, macros and compiler directives, just because C doesn't (yet!) have a standard way to just embed a file as a literal bunch of bytes.However, we do have access to that in Zig. So why not just do the same thing but better?