# I am the Watcher. I am your guide through this vast new twtiverse.
# 
# Usage:
#     https://watcher.sour.is/api/plain/users              View list of users and latest twt date.
#     https://watcher.sour.is/api/plain/twt                View all twts.
#     https://watcher.sour.is/api/plain/mentions?uri=:uri  View all mentions for uri.
#     https://watcher.sour.is/api/plain/conv/:hash         View all twts for a conversation subject.
# 
# Options:
#     uri     Filter to show a specific users twts.
#     offset  Start index for quey.
#     limit   Count of items to return (going back in time).
# 
# twt range = 1 20
# self = https://watcher.sour.is/conv/owvsdgq
movq
www.uninformativ.de
View Thread
A GTK 4 application showing an empty window uses about 160 MB of RAM:

$ wget https://movq.de/v/138ab3e622/win.c
$ cc -Wall -Wextra -o win win.c $(pkg-config --cflags --libs gtk4)
$ ./win

It also takes several seconds to start on my machine because it is compiling shaders and initializing DRI (it’s faster on the second run, unless you happen to lose ~/.cache/mesa_shader_cache/). This might be a hint as to why it’s using so much memory: There’s obviously much more going on behind the scenes these days, not just a little bit of internal housekeeping and then creating a window.
movq
www.uninformativ.de
View Thread
A GTK 4 application showing an empty window uses about 160 MB of RAM:

$ wget https://movq.de/v/138ab3e622/win.c
$ cc -Wall -Wextra -o win win.c $(pkg-config --cflags --libs gtk4)
$ ./win

It also takes several seconds to start on my machine because it is compiling shaders and initializing DRI (it’s faster on the second run, unless you happen to lose ~/.cache/mesa_shader_cache/). This might be a hint as to why it’s using so much memory: There’s obviously much more going on behind the scenes these days, not just a little bit of internal housekeeping and then creating a window.
movq
www.uninformativ.de
View Thread
A GTK 4 application showing an empty window uses about 160 MB of RAM:

$ wget https://movq.de/v/138ab3e622/win.c
$ cc -Wall -Wextra -o win win.c $(pkg-config --cflags --libs gtk4)
$ ./win

It also takes several seconds to start on my machine because it is compiling shaders and initializing DRI (it’s faster on the second run, unless you happen to lose ~/.cache/mesa_shader_cache/). This might be a hint as to why it’s using so much memory: There’s obviously much more going on behind the scenes these days, not just a little bit of internal housekeeping and then creating a window.
mckinley
twtxt.net
View Thread
@movq That memory usage rivals Electron, which runs an instance of Chromium for each program. What do you need shaders for, and why can't you turn them off?
mckinley
twtxt.net
View Thread
@movq That memory usage rivals Electron, which runs an instance of Chromium for each program. What do you need shaders for?
prologic
twtxt.net
View Thread
~160MB of memory just to show an empty window?! And some think a few (single digit) MB of memory is bad for Go web apps that serve "Hello World" 😅~
prologic
twtxt.net
View Thread
~160MB of memory just to show an empty window?! And some think a few (single digit) MB of memory is bad for Go web apps that serve "Hello World" 😅~
prologic
twtxt.net
View Thread
~160MB of memory just to show an empty window?! And some think a few (single digit) MB of memory is bad for Go web apps that serve "Hello World" 😅~
prologic
twtxt.net
View Thread
Have we really gotten that lazy and inefficient? 🤔
prologic
twtxt.net
View Thread
Have we really gotten that lazy and inefficient? 🤔
prologic
twtxt.net
View Thread
Have we really gotten that lazy and inefficient? 🤔
abucci
anthony.buc.ci
View Thread
@movq
Doesn't even compile on my system, which is apparently broken:


> cc -Wall -Wextra -o win win.c $(pkg-config --cflags --libs gtk4)                                                                                                        
cc: error: unrecognized argument in option ‘-mfpmath=sse -msse -msse2 -pthread -I/usr/include/gtk-4.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/x86_64-linux-gnu -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/graphene-1.0 -I/usr/lib/x86_64-linux-gnu/graphene-1.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -lgtk-4 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lgraphene-1.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0’
cc: note: valid arguments to ‘-mfpmath=’ are: 387 387+sse 387,sse both sse sse+387 sse,387
abucci
anthony.buc.ci
View Thread
@movq If I understand it correctly, gtk4 renders using OpenGL. That means some of that RAM that appears to be allocated is actually some trick of the OpenGL driver so that it can map address in RAM space to the GPU's VRAM (depends a lot on your setup though).

What happens if you run it with GSK_RENDERER=cairo set?
abucci
anthony.buc.ci
View Thread
@movq If I understand it correctly, gtk4 renders using OpenGL. That means some of that RAM that appears to be allocated is actually some trick of the OpenGL driver (depends a lot on your setup though).

What happens if you run it with GSK_RENDERER=cairo set?
movq
www.uninformativ.de
View Thread
@abucci Yes, that appears to be the case. I stumbled upon GSK_RENDERER=cairo a while ago – it helps with the startup times and a little bit with memory consumption, which is down to about 130 MB.

Still quite heavy and startup times are noticeably longer than GTK 3. It’s not *that* much, but it’s there.

In my case, I wanted to port xiate from GTK 3 to GTK 4. But that much memory usage for just one terminal window (of which there are usually *many*, so we’re talking about gigabytes here) is too much. GTK might have its use cases, but I think it’s no longer the right toolkit for me.

I don’t want to hate on it too much. I know too little of the internal details of all this, so I don’t have an informed opinion.

(Before anyone suggests it: Yes, I could have *one* process show many terminal windows. That would be a lot faster and would use a lot less memory. But I explicitly do not want that. xiate used to have this model – until one day at work, a bug in the terminal library VTE crashed all my terminal windows at once. It really only crashed one *window*, but since they all ran in the same *process*, they were all gone. This is unacceptable.)
movq
www.uninformativ.de
View Thread
@abucci Yes, that appears to be the case. I stumbled upon GSK_RENDERER=cairo a while ago – it helps with the startup times and a little bit with memory consumption, which is down to about 130 MB.

Still quite heavy and startup times are noticeably longer than GTK 3. It’s not *that* much, but it’s there.

In my case, I wanted to port xiate from GTK 3 to GTK 4. But that much memory usage for just one terminal window (of which there are usually *many*, so we’re talking about gigabytes here) is too much. GTK might have its use cases, but I think it’s no longer the right toolkit for me.

I don’t want to hate on it too much. I know too little of the internal details of all this, so I don’t have an informed opinion.

(Before anyone suggests it: Yes, I could have *one* process show many terminal windows. That would be a lot faster and would use a lot less memory. But I explicitly do not want that. xiate used to have this model – until one day at work, a bug in the terminal library VTE crashed all my terminal windows at once. It really only crashed one *window*, but since they all ran in the same *process*, they were all gone. This is unacceptable.)
movq
www.uninformativ.de
View Thread
@abucci Yes, that appears to be the case. I stumbled upon GSK_RENDERER=cairo a while ago – it helps with the startup times and a little bit with memory consumption, which is down to about 130 MB.

Still quite heavy and startup times are noticeably longer than GTK 3. It’s not *that* much, but it’s there.

In my case, I wanted to port xiate from GTK 3 to GTK 4. But that much memory usage for just one terminal window (of which there are usually *many*, so we’re talking about gigabytes here) is too much. GTK might have its use cases, but I think it’s no longer the right toolkit for me.

I don’t want to hate on it too much. I know too little of the internal details of all this, so I don’t have an informed opinion.

(Before anyone suggests it: Yes, I could have *one* process show many terminal windows. That would be a lot faster and would use a lot less memory. But I explicitly do not want that. xiate used to have this model – until one day at work, a bug in the terminal library VTE crashed all my terminal windows at once. It really only crashed one *window*, but since they all ran in the same *process*, they were all gone. This is unacceptable.)
movq
www.uninformativ.de
View Thread
@prologic

> Have we really gotten that lazy and inefficient? 🤔

That’s the question. It certainly strikes me as odd that everything keeps getting bigger, heavier, slower all the time. But why is that? I refuse to believe that this is just incompetence. 😅
movq
www.uninformativ.de
View Thread
@prologic

> Have we really gotten that lazy and inefficient? 🤔

That’s the question. It certainly strikes me as odd that everything keeps getting bigger, heavier, slower all the time. But why is that? I refuse to believe that this is just incompetence. 😅
movq
www.uninformativ.de
View Thread
@prologic

> Have we really gotten that lazy and inefficient? 🤔

That’s the question. It certainly strikes me as odd that everything keeps getting bigger, heavier, slower all the time. But why is that? I refuse to believe that this is just incompetence. 😅