Thursday, June 11, 2026

One PolyData Mapper Instead of Two: Measuring Vertex Pulling on the DesktopVTK ships two OpenGL polydata mappers that do the same job two different ways. We maintain both. I wrote the second WebGL2/GLES3.0 mapper back in 2023 due to a need for polydata rendering in VTK.wasm using vertex pulling. It's called vertex pulling since it's the vertex shader that decides which vertex data to read vs the traditional way where vertex data is supplied automatically via attributes. The historical reason for keeping them separate was a performance belief: vertex pulling is too slow for the desktop. We turned that belief into measurements on a native NVIDIA GL stack, and it does not hold up. With a two-line change: an indexed draw, vertex pulling can match the classic interleaved-VBO mapper on GPU time across every workload we tried, it carries a realistic 4-attribute vertex with no penalty, and adds zero CPU overhead per frame. The assumption that kept the mappers apart is no longer relevant. This post shows the numbers and argues we should merge the two mappers.📝Kitware Inc
Introducing Qt's Figma Design System Extraction Skills for DevelopersRecreating a design system manually in QML is a laborious task for a Qt developer. A typical Figma design system can include hundreds of design tokens for colors, typography, spacing, radii, shadows, and motion durations - plus dozens of UI components, each with multiple variants and states. Every value has to be transcribed precisely, and even small mismatches can quietly desynchronize the implementation from the Figma source. Two new AI skills close the design-system-to-code gap between Figma and Qt. The Qt Figma Token Extraction skill converts your Figma design tokens directly into QML singletons. The Qt Figma Component Generation skill then turns your Figma component library into idiomatic QML controls that consume those singletons. Together they automate the full design-system handoff. The skills delegate this entire workflow to an AI agent, which connects to Figma, reads the design system, and produces clean, idiomatic QML ready to drop into a Qt project.📝Qt Blog

If this page is useful, please consider donating a coffee

Wednesday, June 10, 2026

Modern C++ Support in CLion: What’s NewModern C++ makes advanced high-performance techniques more accessible, with features like compile-time computation, zero-overhead abstractions, and expressive template code. But as your codebase grows, your ability to use these techniques productively depends heavily on how well your tooling understands them. Without proper language engine support, modern C++ features can lead to false positives, broken navigation, […]📝CLion : A Cross-Platform IDE for C and C++ | The JetBrains Blog

Tuesday, June 9, 2026

Monday, June 8, 2026

Faking keyword arguments to functions in C++One of the many nice language features in Python are keyword arguments. They make some types of APIs concise and readable. Like so: Unfortunately C does not have keyword arguments and, by extension, neither does C++. Adding them as a language feature would take 15-20 years of effort, most of which would consist of trying to convince people via email that such a feature is important and should be added. There have been attempts to implement this via macros and template magic ( link ), but they have not seen widespread usage probably because they are using macros and template magic. However it turns out that with modern language features you can fake keyword arguments fairly convincingly. Like so: The add_argument method takes a single argument which is a struct. The extra curly braces inside the parentheses boil down to "whatever the underlying argument is, construct it in place with these parameters". The dotted names are designated initializers, so those fields get the specified value whereas other fields get their default values. And there you go, keyword arguments in C++. You just have to squint a bit and pretend not to see the extra curly braces.📝Nibble Stew

Sunday, June 7, 2026

Recent LLVM hash table improvementsLLVM has several hash tables. They used quadratic probing with in-band sentinel keys (empty, tombstone); recent work has been replacing that with linear probing with tombstone key removed. DenseMap (replacement for std::unordered_map ): DenseMapInfo::getEmptyKey() / getTombstoneKey() . DenseSet : implemented using DenseMap compiler-rt/lib/sanitizer_common/sanitizer_dense_map.h ports the implementation for sanitizers. SmallPtrSet (replacement for std::unordered_set ): hard-coded -1 (empty) and -2 (tombstone). StringMap (replacement for std::unordered_map ) StringSet : implemented using StringMap For the open-addressed DenseMap and SmallPtrSet , pointers, references, and iterators are invalidated by insert. StringMap is different: each entry lives in a heap-allocated StringMapEntry node, so entry pointers survive grow. std::unordered_map , being node-based, keeps surviving-element pointers valid across both insert and erase and only invalidates the erased element's own iterator. LLVM code rarely needs that stronger contract — callers do not hold long-lived references into the container across mutation — and that gap is what gives pass to relocating erase and bit-array occupancy. Recently, Tombstones have been removed from DenseMap and SmallPtrSet. erase() also invalidates pointers. DenseMap has also retired its empty-key sentinel, leading to significant performance improvements. DenseMap with integer keys ( int / unsigned / size_t ) had -1 / -2 reserved — a footgun, now fixed. StringMap got Algorithm R deletion too. Its entries are separately heap-allocated, so erase keeps entry pointers valid but invalidates iterators; erase-while-iterating moved to remove_if .📝MaskRay

Saturday, June 6, 2026

Friday, June 5, 2026

I'm Allowing AI Use in my LibrariesI’ve taken the decision to allow AI use for PRs to my libraries. I personally believe these tools can be a net add (with lots of straight jackets and caveats), but I also think we’ve reached a point where I can’t really be sure whether the incoming PR requests are from people using AI tooling to help them, or just free roaming OpenClaw instances that are masking their AI nature very well, and so it feels like I’d be firmly swimming against the current as a very part-time open source contributor to try and police this. To be an open and clear about my use of AI I’ve cut pre-ai releases for all my libraries so you can get access to the code from the point before I personally started to use AI tooling (I 100% cannot confirm whether any of the contributions from others to the libraries used AI or not, but I can say with certainty that I did not use AI before these points). The pre-ai tags are: utest.h ubench.h utf8.h json.h subprocess.h hashmap.h I’ve also added a disclaimer to the README.md of each of the repositories that states: AI Usage AI tool use is explicitly permitted in commits to this repository. There is a tagged release pre-ai that denotes the last release where AI tooling was not used. And each of the PRs authored by my pi.dev agent has the footer: 🧙 Conjured by AI via pi.dev using gpt-5.5 As does each commit the AI authored too.📝Neil Henning