Hacker News Reader

Comment by laladrik | Hacker News Reader

Hello, I found that it's difficult to visualize the flamegraph out of the huge amount of data when I was profiling Rust Analyzer. Viewing the flamegraph in a browser (Firefox and Chrome) made it impossible to view. In fact, it was simply frozen. I made this visualizer to solve my problem. Maybe it would help someone else. I leave the link to my article about it, but you can find the link to the project right in the first paragraph.

View on HN

Props to you for making a cool little project, but as somebody who's been involved in Linux graphics a bit: please just let Xlib die. It's an outdated API, even if you ignore the existence of Wayland. For something like fast visualizations, you should really go with something that does offscreen rendering and then blits the result. As long as you're just drawing a bunch of rectangles, even CPU software rendering may be the better solution, though obviously modern tools should use GPU rendering.

I see your journey and how you ended up with Xlib. But I think that's really more of an indictment of the sorry state of GUI in Rust.

I know that's not your job, I just couldn't let this use of Xlib stand uncommented because it's really bad for the larger ecosystem.

> please just let Xlib die

I don't have arguments against the point about Xlib. However, I struggle to use its alternative XCB. XCB doesn't have enough documentation to understand how to use it. In fact, I even looked at the source code of Qt and GTK, but the usage doesn't explain the XCB API. I'd really appreciate if you share with me the data you have. The only thing which I found recently is the wrapper from System76 https://pop-os.github.io/libcosmic/tiny_xlib/index.html. However, it's not a documentation still. I just hope to find some usages of the wrapper and communicate with the original API.

> if you ignore the existence of Wayland

How did you conclude it? I even mentioned it in the article. I don't use it - it's true. However, I can't wait to do it. I've been trying for a couple of years now. Regrettably, I experience various technical difficulties every time. As a result, I still use my i3.

> For something like fast visualizations, you should really go with something that does offscreen rendering and then blits the result.

Do you mean double buffering?

> though obviously modern tools should use GPU rendering

Would you mind elaborating on it?

Re Wayland: Regardless of whether you use Xlib or XCB, your application will use the X protocol, which means it won't run natively on a Wayland desktop but only via Xwayland. Real GUI toolkits nowadays have separate backends for X and Wayland, defaulting to the Wayland backend when run on a Wayland desktop. So while XCB is better than Xlib, you really shouldn't use either.

Re offscreen rendering: This is orthogonal to double buffering but refers to the way modern compositing desktops (including Wayland) work. The application renders the window image into an offscreen surface which is then handed off to the compositor, which blits it to the screen.

Re GPU rendering: You can draw rectangles on a surface on the CPU by simply setting pixel color values in a loop, or you can draw them on the GPU by sending a list of rectangles and have the GPU do the rasterization of the rectangles. Toolkits like Qt or Gtk can do both, depending on the backend that is selected, and will typically default to GPU rendering on modern desktops.

I fail to see the reference to be honest. I remember the term from OpenGL, when I rendered something to a framebuffer (actually its attachmets) and then applied to the current framebuffer. It helped me to do effects like night vision. Does using offscreen rendering imply using OpenGL?

Does GPU rendering mean that I have to involve OpenGL/Vulkan?

I think going for xlib is somewhat missing the forest for the trees. Does it take less memory? Yeah, but you lose out on any gpu assistance you might get for free otherwise. This only really matters as you get to bigger resolutions tho, as you avoid redrawing.

I was surprised to hear the Hotspot isn't fast. I had assumed it would be since it's written in C++.

I've never had hotspot not be fast enough. Even on 20Gb traces, everything is instant.

Only thing that ever takes some time is the initial load of the perf file and filtering (bit still really fast).

Unfortunately, I can't find the original perf file I get the flamegraph https://laladrik.xyz/img/pic.svg out of. However, I can create with a similar bunch of data and provide it soon.

Ok, now I remember what was the deal with Hotspot. It makes it possible to work with a flamegraph of mine. However, it takes almost half a minute to load my perf.data. However! I totally recommend Hotspot over my hack in case when you need to have a comprehensive view of the data. In particular, I love to see the off-CPU load, which my FlameGraphViewer doesn't show.

Reply on news.ycombinator.com