<azonenberg>
Yes. and... i think it was tnt? did some preliminary experimentation into getting glscopeclient running under gles 3.x, whatever version adds compute shaders
<azonenberg>
i do not recall how successful they were
<balrog>
that would be useful because ANGLE allows running GLES on Metal and has fairly complete support
<azonenberg>
Does it have compute shaders specifically?
<balrog>
I'm not sure it's finished yet, but it's at least WIP
<balrog>
How and why is rendering currently tied to the GTK+ version?
<balrog>
(meaning, that we can't use Vulkan independently from GTK+)
<azonenberg>
All of the GUI chrome is in GTK
<azonenberg>
And we rely on GTK to create and manage GL contexts
<azonenberg>
The images displayed in the waveform area are GTKGLArea widgets
nelgau has quit [Read error: Connection reset by peer]
nelgau has joined #scopehal
<d1b2>
<mubes> @azonenberg Finally back to my JTAG stuff....not seeing any problems with these new fixes for speeding up GUI response on SDS2104X. It 'feels' more responsive.
<azonenberg>
Excellent
<azonenberg>
That was the idea
<azonenberg>
I will be adding support for 10-bit mode and the AWG shortly i think
<azonenberg>
Since i need to build out the func gen support in the glscopeclient gui anyway
<d1b2>
<mubes> Bear in mind the 10 bit tops at at 100MHz BW so that'll need to be constrained too
<azonenberg>
It just reduces BW. It doesn't change sample rate
<azonenberg>
afaik
<azonenberg>
So it shouldnt change anything else in the GUI
<d1b2>
<mubes> True
<azonenberg>
It will be just like the programmable ADC resolution on the picoscope 6000E or the lecroy HDO9000
<azonenberg>
We already have APIs defined for this
<balrog>
@mubes I have a SDS2104X+; what is needed for this model? I see that performance isn't that great but according to azonenberg that's pretty much due to firmware and SCPI limitations
<d1b2>
<mubes> Hi. What do you mean what is needed?
<balrog>
what improvements are there to be made (and such)
<azonenberg>
balrog: there are four big TODO items that i recall
<azonenberg>
1) MSO channel support
<balrog>
(is there a tracking issue on github?)
<azonenberg>
2) Support all the different trigger types
<azonenberg>
3) Function generator support
<azonenberg>
4) 10-bit mode support
<azonenberg>
let me check how many of these have tickets as of now
<d1b2>
<mubes> Don't think any of them have, they're just notes in the source file.
<d1b2>
<mubes> The other we could really use is someone who is a GUI wizard....just in case you know anyone!
<azonenberg>
Yes. We are in serious need of a second gui developer
<d1b2>
<mubes> To be clear ... Siglent is perfectly usable within the limitations of the sample rate.
<balrog>
I think I asked this before but... why GTK+? They seem to be lagging so much in supporting newer techs, e.g. vulkan
<azonenberg>
i can't be the hardware project lead and the software project lead and the main backend architect and protocol decode and the performance/optimization guy and the gui dev and...
<balrog>
(which pigeonholes the software to only really run on linux)
<azonenberg>
It runs fine on windows
<azonenberg>
and i think someone got it to at least kinda work on BSD
<azonenberg>
OSX is the main problem platform
<azonenberg>
and that's because of opengl issues not gtk issues
<azonenberg>
balrog: anyway, the tl;dr is that when i started work on the project circa 2010 it was the best option between permissive licensing, platform support, and being generally friendly to work with
<azonenberg>
it would not be impossible to change ui toolkits but it would be enough work we'd need a very good reason to
<azonenberg>
i think at the time qt was GPL not LGPL which ruled it out
<azonenberg>
and i forget why i didnt go with wxwidgets
<azonenberg>
I don't recall all of the factors i considered but at the time it seemed the best choice
<balrog>
probably a stupid question: why do I get much better performance (WFM/s) with the demo scope vs. the siglent?
<balrog>
(with software rendering)
<d1b2>
<mubes> Probably the speed the data comes off the scope/source
<d1b2>
<mubes> Most (all?) of the low end scopes are not optimised for off-boarding data.
<d1b2>
<mubes> +there's a fair bit of data. If you've got 10MSample channel that's 40MBytes of data+overheads
<d1b2>
<mubes> Actually, that's a point...I need to update the graph in the manual now Andrew has fixed the redundant channel handling when they're not switched on.
<balrog>
are any of the higher end scopes doing it over SCPI (or the LAN equivalent)?