<azonenberg>
Variable pitch for a handheld probe is an open problem i've tinkered with a bit
<azonenberg>
but not yet solved satisfactorily
<d1b2>
<louis> Looking at supporting DPI the Right Way
<d1b2>
<louis> Our code in glscopeclient reads the DPI via pango and then generates a scale factor such that 96DPI = scale 1
<d1b2>
<louis> So e.g. on my machine I have Xft.dpi (which is presumably(?) where pango gets it) = 220, so it would produce scale = 2.29, which is about right
<d1b2>
<louis> ImGui::GetWindowDPIScale() appears to bottom out in Platform_GetWindowDpiScale, which seems to be unimplemented on Linux
<d1b2>
<louis> (and regardless, my understanding is that that is a OS-pixel to imgui-pixel mapping factor, not a DPI scale in the conventional sense?)
<d1b2>
<louis> I think this can be queried via glfw though
<azonenberg>
Unimplemented on Linux??
<azonenberg>
interesting
<azonenberg>
But yes, that is my understanding. more precisely, physical display pixels to imgui units
<d1b2>
<louis> glfwGetWindowContentScale appears to do what we want (or at least what I want lol, i.e. it reutnrs 2.29 on my laptop)
<azonenberg>
Well,. then use that
<d1b2>
<louis> looks like you got part way though doing this dpi support actually cuz there's a call to that in VulkanWindow that dosen't do anything with it's response :p
<azonenberg>
Lol
<azonenberg>
Well, well, by all means go finish the job
<azonenberg>
I'm working on eye pattern rendering in ngscopeclient now, and laid the groundwork for file load/save (all of the dialogs and menus and yaml stack init/cleanup and error handling)
<azonenberg>
lain will be writing the actual scopesession serialization code soon
<d1b2>
<louis> That's bizarre... permission problem? I'll have to commandeer your laptop for a bit to look at it
<d1b2>
<azonenberg> @louis: it looks like you are calling the function prior to glfwCreateWindow()
<d1b2>
<azonenberg> maybe on linux it just makes an xlib call and on macos it has to actually use the window to get the scale?
<d1b2>
<azonenberg> fix is probably to make sure the window has been created before you query the DPI
<d1b2>
<louis> Huh. Ok, I'll move that around when I'm next at laptop and see if that resolves it
<d1b2>
<MP> 👍
<d1b2>
<azonenberg> @MP if you want to try on your end, lines 91-93 in VulkanWindow.cpp around GetContentScale() should be moved down a couple lines until they're after the glfwCreateWindow() call completes
<_whitenotifier>
[scopehal-apps] azonenberg 874841d - Initial work on eye pattern rendering in ngscopeclient. So far it's just B&W with no color ramp. See #518.
<_whitenotifier>
[scopehal-apps] azonenberg 0389d70 - Added gradient texture loading. Not actually used for anything yet. See #518.
<d1b2>
<azonenberg> @MP check if 0389d70 fixes it for you
<d1b2>
<MP> having to restart the scope
<d1b2>
<MP> @azonenberg @ louis there anything we can do if we detect getting garbage from the scope
<d1b2>
<MP> @azonenberg affirm on the fix - seems to fix it - what was it?
<d1b2>
<azonenberg> Recovery from scopes spewing trash at us is hard. you can attempt to sync, i think louis has some work on that
<d1b2>
<azonenberg> but really the proper fix is to not get there in the first place
<d1b2>
<azonenberg> that little block in RenderTimeline()
<d1b2>
<azonenberg> an edge case i hadn't previously hit returned early without calling EndChild() first
<d1b2>
<azonenberg> one thing i want to look into, given the prevalence of this error, is RAII-ifying some of the imgui stateful window management functions
<d1b2>
<azonenberg> to ensure if we return we always call the correct End* function