<d1b2>
<sphereinabox> I got this compiled on windows today following the gettingstarted instructions
<d1b2>
<sphereinabox> I found it easier to remove the backslash/line continuation on the "install vulkan dependencies" step
<d1b2>
<sphereinabox> anyway, it looks like there's some weird sizing/rendering I'm seeing that depend on windows DPI scaling. On my laptop the rendered area of the window doesn't get larger as the window does. On both my laptop and desktop a lot of widgets are unusually sized or placed
<d1b2>
<azonenberg> interesting. this may affect windows too then
<d1b2>
<azonenberg> ok this looks like a separate bug, please file a ticket
<d1b2>
<azonenberg> if you have no DPI scaling, does it render to the full window area and track resizes properly?
<d1b2>
<azonenberg> i.e. at 100% scale
<d1b2>
<sphereinabox> yes, but also on my desktop with different DPI scaling it does
<d1b2>
<azonenberg> it works on your desktop. or it fails there?
<d1b2>
<sphereinabox> on my desktop the window contents match the window size, even at 200% dpi scaling (only 1920x1200 resolution)
<d1b2>
<sphereinabox> both however match how they render widgets the wrong size when scaling is over 100%. Notice the tabs are under the icon toolbar and the icons are only the top half of the
<d1b2>
<azonenberg> if not, please file a new ticket
<d1b2>
<sphereinabox> This matches what I'm seeing on my laptop, yes
<d1b2>
<sphereinabox> huh, it happens even with 100% scaling at native res
<d1b2>
<azonenberg> in that case probably same bug. so it looks like we now have two separate users affected
<d1b2>
<azonenberg> both have it working on one windows box and failing on another
<d1b2>
<azonenberg> please comment on that ticket with as much info as you have on OS/driver/hardware differences between the two
<d1b2>
<azonenberg> if you have icon scaling issues that's a separate bug, probably file a new ticket for that
<d1b2>
<azonenberg> guessing we calculate the toolbar height and icon size separately and one is dpi-aware and the other is not
<d1b2>
<sphereinabox> the width of the vertical scale on the right, the width of the grouping on the left have similar sizing issues
<d1b2>
<sphereinabox> and that's the first that has jumped out at me. I just got this running an hour ago and I should sleep
<d1b2>
<azonenberg> ok when you get up please file an issue for the other scaling issue (separate from the resize problem)
<d1b2>
<azonenberg> a detailed list of every single item you find that doesn't scale right would be very helpful
<d1b2>
<azonenberg> ideally with annotated screenshots
<d1b2>
<azonenberg> I don'
<d1b2>
<azonenberg> I don't have any hi-DPI windows systems and i'm the main frontend dev
<d1b2>
<azonenberg> So its difficult for me to validate that
<d1b2>
<sphereinabox> I was able to bump the DPI scaling on my 1920x1200 24" display to 200%... but obviously that makes everything huge so it's not a huge help
<d1b2>
<sphereinabox> on my 1080 displays I could only go up to 175%
<d1b2>
<azonenberg> yeah. anyway, if you can list every misbehaving ui element i can go through line by line and fix most of them in a few minutes
<d1b2>
<azonenberg> this is the kind of thing we want to squish before the upcoming release
<d1b2>
<sphereinabox> here's what 200% at 1920x1200 looks like
<d1b2>
<sphereinabox> usability wise I am surprised that there isn't some universal way to click and drag to pan everywhere, that I have to click and drag on the timeline on the top to pan horizontally... but also I haven't used an oscilloscope with a touchscreen or mouse before
<d1b2>
<azonenberg> Clicking on the timeline to pan might happen eventually, but I want to be careful about avoiding confusion between there and selecting things, placing cursors, etc
<d1b2>
<azonenberg> the main intended navigation for the timeline is scrolling with the mouse wheel
<d1b2>
<azonenberg> which will zoom and center whatever you're on
<d1b2>
<azonenberg> (on the plot)
<d1b2>
<sphereinabox> yeah I was surprised that middle mouse or right mouse or shift+rmb or something wasn't a universal way to click and pan
<d1b2>
<sphereinabox> my mind might be slightly altered by using blender, where you can pan all the 2d windows by dragging with middle mouse. image viewer, nodal graph, curves, timeline, property grid, list of tabs, toolbar, tree view, text console, text editor... lots of stuff
<d1b2>
<sphereinabox> but anyway, I tried touchscreen and it worked about how the instructions would suggest
<d1b2>
<sphereinabox> dragging on the timeline on the top panned left/right. pinch/stretch zoomed in and out (didn't matter if it was horizontal or vertical pinch). vertical drag on the right size scale moved it up or down
Bird|ghosted has joined #scopehal
Bird|otherbox has quit [Read error: Connection reset by peer]
<d1b2>
<sphereinabox> looks like on macos I get the same wide area for vertical scale, but the other scaling issues I noticed aren't happening
<d1b2>
<sphereinabox> I was trying to create a new tab with just one waveform without docking the new tab. Looks like I can add the same stream more than once
<d1b2>
<sphereinabox> weird, GPU load goes up to max when it's not visible, when I'm on another virtual desktop. I'm speculating it's no longer limited to vsync when not on screen
<d1b2>
<sphereinabox> got that link from glfw issue where someone has opposite problem: they want to maintain high framerate when window is hidden. https://github.com/glfw/glfw/issues/975
<d1b2>
<sphereinabox> another web result from my search soemone complains their GLFW app drops from 120FPS to about 80FPS when fullscreen, and that's exactly what I'm seeing ngscopeclient do also. https://discourse.glfw.org/t/mac-fullscreen-issues/2670
<d1b2>
<vipqualitypost> I need to rebuild ngscopeclient on my work PC. this issue was opened when I had a Quadro P2000 (or similar) which was the first nvidia generation to support Vulkan. I think that maybe their drivers are not so good. All the other windows boxes I have used it on are using more modern parts. I recently snuck in an RTX A6000 into my work pc which is a few gens newer so hopefully does not cause the same problems.
<d1b2>
<vipqualitypost> I have access to HiDPI monitors on mac, windows and linux so happy to test any patches related to those
<d1b2>
<azonenberg> that should not be possible, file a ticket
<d1b2>
<azonenberg> interesting. we might want to play in preferences for that or something
<d1b2>
<azonenberg> in particular, right now the event loop is tied to rendering
<d1b2>
<azonenberg> so you dont want to stop the event loop when its off screen
<d1b2>
<azonenberg> as you won't be acquiring data then
<d1b2>
<azonenberg> and you might want to be running protocol decodes or trend plots in the background
<d1b2>
<sphereinabox> the latest imhex release has notes about fixing a similar issue. Looking at their code (window.cpp around commit f6944b15f34cac834cbf345c38c5c7aaf1345e09 for example) it seems like they drop the target FPS to 5 in that case
<d1b2>
<sphereinabox> when searching for that I found someone else in another glfw app commenting that framerate drops when fullscreen on mac. your application does the same. I see drop from 120fps to about 80fps https://discourse.glfw.org/t/mac-fullscreen-issues/2670/4
<d1b2>
<azonenberg> file a ticket so we can figure out how to handle it. this might make sense to do when we decouple waveform event processing from rendering in the future
<d1b2>
<azonenberg> that will be necessary to support use cases like "scope pushing 500 WFM/s of shallow memory depth"
<d1b2>
<azonenberg> it's just technically nontrivial with our current architecture
<d1b2>
<azonenberg> because ideally we would take those 500 waveforms, render all of them to offscreen buffers, composite them, and display 60FPS worth of the composites on your display
<d1b2>
<azonenberg> and we need to support waveform acquisition rates both massively above and massively below the display framerate without any sync issues blocking the other set of threads
<d1b2>
<sphereinabox> I'll try to file tickets this evening my time. Working on other stuff now
<d1b2>
<ehntoo> We had some end of fiscal year capital budget to spend and I picked up a Rigol MHO5104 which I figured I'd contribute scopehal support for. I figured they've had their Android-based firmwares going for a while now, surely it'll be pretty bug-free out of the box. Oh boy, was I ever mistaken. I have found so many bugs just using the scope (trigger levels de-sync, decoders that are broken). While attempting to add support for it to scopehal over
<d1b2>
the last couple of days, I'm beginning to believe that it may just be impossible to build a reliable waveform download with the current firmware. There's some resource leak on the oscilloscope that will eventually cause the whole thing to stop responding to any commands whatsoever. 🫠 So, unless I make some unexpected breakthrough I guess that support patch will come when they release a less-crap firmware.
<d1b2>
<azonenberg> lol
<d1b2>
<azonenberg> yeah instrument firmware is definitely a mixed bag
<d1b2>
<azonenberg> its not just cheap vendors either
<d1b2>
<azonenberg> i have had nothing but pain trying to reliably support the tek MSO4/5/6