Skip to content

Instantly share code, notes, and snippets.

@devrim

devrim/session-log.md

Last active March 17, 2026 22:38
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save devrim/da0a05e9e5eeb5dbcfd714cf3d8967ee to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save devrim/da0a05e9e5eeb5dbcfd714cf3d8967ee to your computer and use it in GitHub Desktop.
Download ZIP
ImGui macOS Retina rendering fix — LuckyEngine
Raw
session-log.md

Session Log — ImGui macOS Retina Fix (2026-03-17)

Prompt 1

Read this repo and write a report about what stage is it for the mac os port of the engine

Response: Comprehensive macOS port status report covering all subsystems (rendering, physics, audio, scripting, editor UI, asset pipeline). Conclusion: ~97% complete MVP, all major subsystems working on Apple Silicon via Vulkan/MoltenVK.

Prompt 2

The imgui passes are drawn at a much higher zoom level that they should, breaking the rendering. Find what can cause this issue, check for DPI scaling on imgui backend and check how the imgui draw commands are executed in the engine

Response: Deep investigation of the ImGui rendering pipeline. Found two issues:

  1. Confirmed bug: Clip rect double-scaling — ImGuiRenderer.cpp:545 calls ScaleClipRects(FramebufferScale) then the per-command loop at line 647 scales again by FramebufferScale. The official imgui_impl_vulkan.cpp never calls ScaleClipRects.

  2. Root cause candidate: Viewport/scissor computed from DisplaySize × FramebufferScale instead of actual framebuffer dimensions. On macOS, surfaceCaps.currentExtent determines swapchain resolution and can differ, causing viewport-to-framebuffer mismatch (2× zoom).

Traced the full pipeline: GLFW backend → io.DisplaySize/io.DisplayFramebufferScale → ImGui::Render() → ImGuiRenderer::Render() → projection matrix → vertex shader → viewport → swapchain.

Prompt 3

Fix this issue

Response: Applied two changes to Hazel/src/Hazel/ImGui/ImGuiRenderer.cpp:

  1. Removed drawData->ScaleClipRects(drawData->FramebufferScale) (line 545)
  2. Replaced fbWidth = DisplaySize * FramebufferScale with actual framebuffer dimensions from framebuffer->getFramebufferInfo()
  3. Derived clip_scale as fbWidth / DisplaySize instead of using FramebufferScale directly

Build succeeded with no errors.

Prompt 4

continue

Response: Confirmed all targets linked successfully (lsp, Ned, LuckyRuntime, Hazel-Server, LuckyEditor). Summarized the fix.

Prompt 5

On the current version, the interface widgets show much bigger than they should be. Find in imgui codebase how to lower the scaling of all the widgets

Response: Investigated the full DPI scaling chain. Found that ImGuiLayer.cpp:258 uses DPI::SetUIScaleFactor(contentScale) where contentScale = 2.0 on macOS Retina. But fbScale is also 2.0 (framebuffer is 2× window size), so widgets don't need extra scaling. The correct formula uiScale = contentScale / fbScale = 1.0 was already documented in comments and used in the DPI-change callback but not at init.

Applied the fix: changed to DPI::SetUIScaleFactor(contentScale / fbScale). Build succeeded.

Prompt 6

commit this change

Response: Committed as a265e2ea1 with message: "fix: correct ImGui widget DPI scaling on macOS Retina"

(User rejected initial attempt that included Co-Authored-By line)

Prompt 7

Dont add claude as co author

Response: Re-committed without Co-Authored-By. Saved feedback to memory for future sessions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment