<d1b2>
<louis> This (PR above) is an open UX question... as PR'ed it dosen't do ->SetTriggerOffset() until you release the drag, which means you don't see the waveform offset move as you drag anymore. This is probably a perf win in some cases, but isn't necessarily wanted.
<azonenberg>
yeah i don't like that. it should definitely move as you drag
<d1b2>
<louis> Maybe we still want to issue ->SetTriggerOffset() but continue to display the (possibly not-actual after rounding) drag position, that might be better. May want to only issue trigger offset changes at X Hz to avoid tons of traffic?
<azonenberg>
Rate limiting stuff like that is very much a nice-to-have. I think it would probably be best done in the driver
<azonenberg>
i.e. every call update the cache
<azonenberg>
but rate limit updates to be no more than one per X time
<azonenberg>
the challenge is if you have one more set call after you send a message then stop dragging the cursor
<azonenberg>
that does have to get flushed to hardware eventually
<azonenberg>
in general with all of the gain/offset commands there is potential for optimization there
<azonenberg>
right now i issue one call every mouse event from the gui library
<d1b2>
<louis> Sure, changed to update while dragging (while keeping drag position decoupled from scope's view of it's trigger pos to avoid snapping on granular triggers)
<d1b2>
<louis> I think the general rate-limiting thing there can be punted to a different issue / done more generally (either in glscope or in scopehal with some shared helper)
<azonenberg>
Yeah there is a lot of UI work to do in that regard
<azonenberg>
this is what happens when i'm the sole ui dev for the most part :p
<azonenberg>
lots of little things that are objectively nice, but i have to put aside to fry bigger fish
<d1b2>
<louis> I would be inclined to do it in glscope, since I think the behavior we want is issuing ->SetTriggerOffset() when (it's been X ms since last issued AND it's been dragged by at least one pixel at the current scale) OR when the drag is released
<d1b2>
<louis> and then similar logic w/o the one pixel condition for trigger level
<azonenberg>
Yeah
<azonenberg>
Feel free to explore that
<azonenberg>
the main thing is, i want the line to move nicely in the gui as you drag
<azonenberg>
it has to update interactively if you drag while the trigger is armed
<azonenberg>
you want it to follow the trigger position if you hold the mouse down for several acquisitions
<azonenberg>
(but it's ok if there's a small lag there)
<d1b2>
<louis> 👍. That's what the current behavior in PR#415 is now.
<d1b2>
<louis> I will look at rate limiting drag UI interactions in general in another PR
<azonenberg>
So do you think 596/415 are ready to merge now?
<_whitenotifier-e>
[scopehal] 602p b13d4fc - Recieve actual trigger position from instrument to update scopehal's view
<_whitenotifier-e>
[scopehal] azonenberg 07c8061 - Merge pull request #596 from 602p/defacto_trigger DSLabs: Recieve actual trigger position from instrument
<_whitenotifier-e>
[scopehal-apps] azonenberg 3ac3048 - Merge pull request #415 from 602p/defacto_trigger Decouple trigger offset drag position (for scopes with granular triggers)
<azonenberg>
Oh this is nice. I'm switching the sniffer board from a 4:1 to a 2:1 memory controller. Because I'm using DDR3L, the Fmax of the IO at 1.35V ends up being the limiting factor more so than the core
<azonenberg>
And by running at 2:1 I save 1.1K LUTs, almost 400 LUTRAMs and 700 FFs
<azonenberg>
The fabric side interface drops from 512 bits at 162.5 MHz to 256 bits at 325 MHz
<azonenberg>
Which is a much better match to the 312.5 MHz that the logic analyzer capture runs at
<azonenberg>
and means less buffering and width conversion is needed