New top story on Hacker News: Show HN: Asdf Overlay – High performance in-game overlay library for Windows

Show HN: Asdf Overlay – High performance in-game overlay library for Windows
10 by storycraft | 2 comments on Hacker News.
I am making a open source overlay library. Game overlay is for rendering contents on top of game screen. Representative examples are Discord and Steam in-game overlay. They are complicated because it has to hook rendering part of a game. Asdf overlay provides easy to use interfaces for rendering on top of game screen. I recognize game performance degradation due to overlay rendering, so GPU shared texture was used to avoid CPU framebuffer copy. Asdf Overlay is capable of rendering full screen overlay without noticeable performance loss.

New top story on Hacker News: Show HN: Open-source, visual-first Cursor for Designers

Show HN: Open-source, visual-first Cursor for Designers
53 by hoakiet98 | 36 comments on Hacker News.
Hey HN, I’m Kiet – one half of the two-person team building Onlook, an open-source [ https://ift.tt/ibJqU6Y ] visual editor that lets you edit and create React apps live on an infinite canvas. We launched Onlook [1][2] as a local-first Electron app almost a year ago. Since then, “prompt-to-build” tools have blown up, but none let you design and iterate visually. We fixed that by taking a visual-first, AI-powered approach where you can prompt, style, and directly manipulate elements in your app like in a design tool. Two months ago, we decided to move away from Electron and rewrite everything for the browser. We wanted to remove the friction of downloading hundreds of MBs and setting up a development environment just to use the app. I wrote more here [3] about how we did it, but here are some learnings from the whole migration: 1. While most of the React UI code can be reused, mapping from Electron’s SPA experience to a Next.js app with routes is non-trivial on the state management side. 2. We were storing most of the data locally as large JSON objects. Moving that to a remote database required major refactoring into tables and more loading states. We didn’t have to think as hard about querying and load time before. 3. Iframes in the browser enforce many more restrictions than Electron webview. Working around this required us to inject code directly into the user project in order to do cross-iframe communication. 4. Keeping API keys secure is much easier on a web application than an Electron app. In Electron, every key we leave on the client can be statically accessed. Hence, we had to proxy any SDK we used that required an API key into a server call. In the web app, we can just keep the keys on the server. 5. Pushing a release bundle in Electron can take 1+ hours. And some users may never update. If we had a bug in the autoupdater itself, certain users could be “stranded” in an old version forever, and we’d have to email them to update. Though this is still better than mobile apps that go through an app store, it’s still very poor DX. How does Onlook for web work? We start by connecting to a remote “sandbox” [4]. The visual editing component happens through an iframe. We map the HTML element in the iframe to the location in code. Then, when an edit is made, we simulate the change on the iframe and edit the code at the same time. This way, visual changes always feel instant. While we’re still ironing out the experience, you can already: - Select elements and prompt changes - Update TailwindCSS classes via the styling UI - Draw in new divs and elements - Preview on multiple screen sizes - Edit your code through an in-browser IDE We want to make it trivial for anyone to create, style, and edit codebases. We’re still porting over functionalities from the desktop app — layers, fonts, hosting, git, etc. Once that is done, we plan on adding support for back-end functionalities such as auth, database, and API calls. Special thank you to the 70+ contributors who have helped create the Onlook experience! I think there’s still a lot to be solved for in the design and dev workflow, and I think the tech is almost there. You can clone the project and run it from our repo (linked to this post) or try it out at https://beta.onlook.com where we’re letting people try it out for free. I’d love to hear what you think and where we should take it next :) [1] https://ift.tt/NgKi21M [2] https://ift.tt/ncJ43ys [3] https://ift.tt/G9vVInk... [4] Currently, the sandbox is through CodeSandbox, but we plan to add support for connecting to a locally running server as well.

Tuesday, May 27, 2025

New top story on Hacker News: Show HN: Maestro – A Framework to Orchestrate and Ground Competing AI Models

Show HN: Maestro – A Framework to Orchestrate and Ground Competing AI Models
4 by defqon1 | 0 comments on Hacker News.
ive spent the past few months designing a framework for orchestrating multiple large language models in parallel — not to choose the “best,” but to let them argue, mix their outputs, and preserve dissent structurally. It’s called Maestro heres the whitepaper https://ift.tt/8wM0kNW (Narrative version here: https://ift.tt/ItDU74T... ) Core ideas: Prompts are dispatched to multiple LLMs (e.g., GPT-4, Claude, open-source models) The system compares their outputs and synthesizes them It never resolves into a single voice — it ends with a 66% rule: 2 votes for a primary output, 1 dissent preserved Human critics and analog verifiers can be triggered for physical-world confirmation (when claims demand grounding) The feedback loop learns not only from right/wrong outputs, but from what kind of disagreements lead to deeper truth Maestro isn’t a product or API — it’s a proposal for an open, civic layer of synthetic intelligence. It’s designed for epistemic integrity and resistance to centralized control. Would love thoughts, critiques, or collaborators.

New top story on Hacker News: Show HN: Free mammogram analysis tool combining deep learning and vision LLM

Show HN: Free mammogram analysis tool combining deep learning and vision LLM
3 by coolwulf | 3 comments on Hacker News.
I've built Neuralrad Mammo AI, a free research tool that combines deep learning object detection with vision language models to analyze mammograms. The goal is to provide researchers and medical professionals with a secondary analysis tool for investigation purposes. Important Disclaimers: - NOT FDA 510(k) cleared - this is purely for research investigation - Not for clinical diagnosis - results should only be used as a secondary opinion - Completely free - no registration, no payment, no data retention What it does: 1. Upload a mammogram image (JPEG/PNG) 2. AI identifies potential masses and calcifications 3. Vision LLM provides radiologist-style analysis 4. Interactive viewer with zoom/pan capabilities You can try it with any mass / calcification mammo images, e.g. by searching Google: mammogram images mass Key Features: - Detects and classifies masses (benign/malignant) - Identifies calcifications (benign/malignant) - Provides confidence scores and size assessments - Generates detailed analysis using vision LLM - No data storage - images processed and discarded Use Cases: - Medical research and education - Second opinion for researchers - Algorithm comparison studies - Teaching tool for radiology training - Academic research validation The system is designed specifically for research investigation purposes and to complement (never replace) professional medical judgment. I'm hoping this can be useful for the medical AI research community and welcome feedback on the approach. Address: https://ift.tt/4KxIORA

New top story on Hacker News: Show HN: Zli – A Batteries-Included CLI Framework for Zig

Show HN: Zli – A Batteries-Included CLI Framework for Zig
13 by caeser | 0 comments on Hacker News.
I built zli, a batteries-included CLI framework for Zig with a focus on DX and composability. Key features: - Typed flags with default values and help output - Rich formatting, and layout support - Command trees with isolated execution logic - It’s designed to feel good to use, not just to work. - Built for real-world CLI apps, not toy examples. Would love feedback, feature ideas, or thoughts from other Zig devs. repo here: https://ift.tt/ISPflAz

New top story on Hacker News: Show HN: Vaev – A browser engine built from scratch (It renders google.com)

Show HN: Vaev – A browser engine built from scratch (It renders google.com)
14 by monax | 4 comments on Hacker News.
We’ve been working on Vaev, a minimal web browser engine built from scratch. It supports HTML/XHTML, the CSS cascade, @page rules for pagination, and print-to-PDF rendering. It even handles calc(), var(), and percentage units—and yes, it renders Google.com (mostly). This is an experimental project focused on learning and exploration. Networking is basic ( http:// and file:// only), and grid layouts aren’t supported yet, but we’re making progress fast. We’d love your thoughts and feedback.

Friday, May 16, 2025

New top story on Hacker News: Show HN: KVSplit – Run 2-3x longer contexts on Apple Silicon

Show HN: KVSplit – Run 2-3x longer contexts on Apple Silicon
75 by dipampaul17 | 9 comments on Hacker News.
I discovered that in LLM inference, keys and values in the KV cache have very different quantization sensitivities. Keys need higher precision than values to maintain quality. I patched llama.cpp to enable different bit-widths for keys vs. values on Apple Silicon. The results are surprising: - K8V4 (8-bit keys, 4-bit values): 59% memory reduction with only 0.86% perplexity loss - K4V8 (4-bit keys, 8-bit values): 59% memory reduction but 6.06% perplexity loss - The configurations use the same number of bits, but K8V4 is 7× better for quality This means you can run LLMs with 2-3× longer context on the same Mac. Memory usage scales with sequence length, so savings compound as context grows. Implementation was straightforward: 1. Added --kvq-key and --kvq-val flags to llama.cpp 2. Applied existing quantization logic separately to K and V tensors 3. Validated with perplexity metrics across context lengths 4. Used Metal for acceleration (with -mlong-calls flag to avoid vectorization issues) Benchmarked on an M4 MacBook Pro running TinyLlama with 8K context windows. Compatible with Metal/MPS and optimized for Apple Silicon. GitHub: https://ift.tt/ux0jOid

New top story on Hacker News: Show HN: Feedsmith — Fast parser & generator for RSS, Atom, OPML feed namespaces

Show HN: Feedsmith — Fast parser & generator for RSS, Atom, OPML feed namespaces
10 by macieklamberski | 3 comments on Hacker News.
Hi HN! While working on a project that involves frequently parsing a lot of feeds, I needed a fast JavaScript-based parser to extract specific fields from feed namespaces. Existing Node packages were either too slow or merged all feed formats, losing namespace information. So I decided to write it myself and created this NPM package with a simple API. Feedsmith supports all feed formats and many popular namespaces, including: Podcast, Media, iTunes, Dublin Core, and more. It can also parse and generate OPML files. I am currently adding support for more namespaces and feed generation for RSS, Atom and RDF. The library grew into something bigger than I initially anticipated, so I also started creating a dedicated documentation website to describe all the features.