Comment by ๐ meidam
Re: "Working on some things for the next version of Profectus,..."
@clseibold Hehe, okay. You are also making the client specifically because you wanted there to be a client, which supports your own internet protocol called Scroll right? And then I guess you might as well support the other ones
Also makes sense to put much effort into the gemini protocol since that currently is the most popular of the ones that you are supporting.
You having fun making your client do all sorts of things?
Jun 03 ยท 5 weeks ago
6 Later Comments โ
๐ meidam ยท Jun 03 at 12:02:
How's the TUI client with libvaxis on zig going btw?
๐ clseibold [OP] ยท Jun 03 at 12:11:
@meidam Well, I did start working on the browser after having devised the scroll protocol, but the idea of creating my own gui browser happened before I even wanted to do anything like the Scroll protocol at all. So while the scroll protocol helped drive me to actually start the project, because I wanted to develop the protocol spec alongside client and server implementations for testing purposes, it isn't the sole reason Profectus exists.
Profectus started before Alhena, afaik, so personally, I saw a gap in gui gemini browsers for very polished custom-made cross-platform browsers for Gemini, where Lagrange was the only main one that I felt was worth using. So that's where the idea for making my own browser comes from.
Yeah, it's been fun working on Profectus. About 80% of the project was done within a couple days, even porting my custom gui over from the Odin programming language to Golang, because I didn't want to have to deal with making my own openssl bindings in Odin, and figuring out the threading situation (goroutines are just easier). The other 20% was trying to optimize things, or adding audio support, or whatever, or bug fixing, or whatever. I had to rewrite the layout code a couple times since I wrote the first version of it in Odin, lol.
Now that it's been over a year though, after this Beta 1.3 release, I want to move back over to either Zig or Odin. Golang has a lot of downsides for what I want to achieve with Profectus, unfortunately.
Anyways, the hardest part about Profectus has been trying to make my gui code more efficient.
The GUI Layout calculations are hard to modify because it's complicated. I also originally wrote the layout function to be recursive, and each GUI Element is basically like a flexbox that contains child elements, so the tree has a lot of nested stuff.
The GUI Layout code though is very flexible. It's flexbox, but you can also have it auto-size elements so it fits its children contents, you can enable "autoAsMin" where the auto-size is the minimum size of the element. There's max size as well. And just like in flexbox, there's a direction (vertical and horizontal) that child elements are stacked as. And you can, instead of Flex sizing, do pixel sizing too, and the sibling elements that are Flex will fill in the rest of the space. It's pretty cool, imo, but also probably very non-optimized.
And the font rendering is not as fast as it should be. In the Odin version of the GUI code (which I use for Tempus Calendar), I used stb_ttf, along with my own glyph atlas, and it was very fast for getting the size of strings (even wrapped) separately from the rendering of them, but it didn't support RTL or Emojis or fallback fonts properly.
With SDL2_ttf, the text rendering was so basic that it had only a function to render a string into a texture, and then you had to store that texture across frames so you aren't creating a new texture every frame. It literally didn't use a glyph atlas! And you couldn't get the size of a wrapped string without also rendering it into a texture.
And when the size of the window or layout changes, you have to rerender all of the textures of the entire document so that you can get the new widths and heights of all the strings so that you know the size of the document.
A similar problem seems to also be in lagrange. If you are viewing a somewhat large-ish (even the Gemini spec) gemtext document, and you resize the window so that the document has to re-wrap everything, you'll see that Lagrange's resizing slows way down!
Now with SDL3, there's a new TextEngine that uses a glyph atlas! And you can get the size of strings without also rendering them to a texture. And it supports fallback fonts, so I can combine a regular font with an emoji font, too. Unfortunately, the text wrapping changes is still slow, and I have no idea why.
And also, because I use Golang, there's extra stuff that Golang has to do to communicate with the SDL3 library because of the different calling conventions and Golang's concurrency model, so that slows things down just a tad bit more too.
So the hardest part of Profectus has been getting the text rendering to be performant enough to be usable. Right now, as long as you aren't making the window small enough to require changing the document's wrapping width, then it's performant enough to be smooth. But once you resize your window width to be small, it completely slows down, or stalls if the document is way too big.
But to be fair, this is the exact same problem that Lagrange has. Anyways, now I'm trying to research how the hell web browsers implement text layout to be so efficient! I do wonder though if SDL3_ttf's TextEngine layout stuff is just slow though.
๐ clseibold [OP] ยท Jun 03 at 12:23:
@meidam As for libvaxis, I got annoyed with it, because of some things in its immediate mode API that are not great, and make things so unnecessarily difficult to deal with. So I put it on the backburner to work on my Gemini MMO game Biomebound, lol.
๐ clseibold [OP] ยท Jun 03 at 12:40:
@meidam I do think part of what might be slowing down my gui code could be that I represent my tree as an element with a linked list of children. The fact that it's a linked list allows me to create *all* elements within one single arena/dynamic array *out of order*, which can then be freed in bulk at the end of a frame, but I pay for that with both cache misses and a bunch of pointer indirections when trying to traverse the gui element tree.
So I think the next thing I want to try is removing the linked lists and using something else to store the children of an element in the tree.
I didn't run into these problems with Tempus Calendar much because the GUI for that isn't adding tons of elements in the tree like what happens with Profectus, and Tempus Calendar's UI doesn't actually use any proper scrolling system, and fakes the scrolling by doing what is essentially "virtual lists" but where you scroll by-element instead of by-pixel, lol.
๐ฆ Houjimmy ยท Jun 15 at 10:06:
Want't Profectus mainly a browser made to your own protocol?
How are the Scroll project going? I tried to use once but got confused.
๐ clseibold [OP] ยท Jun 16 at 22:19:
@Houjimmy No, Profectus was never exclusively scroll protocol.
I'm working on ideas for a big update to the Scroll Protocol, but it's taking a while. I'm working on implementing some of the new things in Profectus now to see how they work out.
Original Post
Working on some things for the next version of Profectus, my Gemini browser: SDL3, and Emojis and RTL text now works! New text-to-speech UI (using piper) with keyboard commands to navigate the page Built-in Misfin Client Client certificate support Even better HiDPI scaling. Prefectus 1.2 already had decent scaling. Now it should be more accurate and more responsive to display changes. Also, it works better than in Lagrange :P Input improvements Other features I'm considering: Built-in calendar...
๐ฌ 9 comments ยท 2 likes ยท Jun 02 ยท 5 weeks ago
Source