04:19 <d1b2> <dannas> @azonenberg I agree about the formatting. I'll update the PR tonight with formatting fixes and rephrase/expand the comments a bit. Yhank you for the fast feedback.

04:22 <d1b2> <dannas> And its a good oppurturnity for me relearn what Ive forgotten about the linux graphics stack. I didn't think that glx was still used on midern x-servers. So Ill read up a bit more to make sure I fully understand whats going on

20:12 <_whitenotifier-1> [scopehal-apps] dannas synchronize pull request #391: WaveformArea: Ignore GLX errors for Wayland - https://git.io/J6FYJ

20:15 <d1b2> <dannas> I assume that gtk::GLArea takes care of providing a context for opengl, so we don't need GLEW to query for EGL (Wayland) or GLX (Xorg). We do use ARB extensions that are queried for inside the GLX-path though. Luckily that function appears to work for both EGL and GLX. I've updated my PR with minor formatting changes and expanded the comment.

20:17 <d1b2> <dannas> My 45min hobby-coding time for today is over. Time for bed. Tomorrow evening I will try actually running glscopeclient against my Siglent SDS1104X-E. I believe there was someone in here asking about the status for that scope a few days back. Hopefully I'll know tomorrow evening.

20:17 <d1b2> <sys64738> (I've used GtkGLArea (from C) before, and yes, you do not need to provide a separate context)

20:19 <d1b2> <dannas> @sys64738 Yeah, then we don't really need the GLX/EGL specific initialization that GLEW does. Once 2.2.0 has trickled down into the linux distributions the code in my PR can be simplified.

20:20 <d1b2> <dannas> I haven't done any graphics programming at all (except some OpenGL tutorial way back in the past). I wonder what the ARB extensions are about and why there are EGL and GLX specific calls for retrieving them.

20:20 <d1b2> <dannas> Luckily it seems like the GLX ARB queries are useable on Wayland as well

23:15 <azonenberg> Sooo i made the mistake of throwing ps6000d in VTune

23:15 <azonenberg> I say mistake, because it showed me that (unsurprisingly) my code which was basically just calling the pico api and shoving it into a socket wasn't a bit bottleneck

23:15 <azonenberg> big*

23:16 <azonenberg> and the pico driver was pegging a core. Which probably means it can be made faster

23:17 <azonenberg> I do not need another project

23:17 <azonenberg> I don't

23:17 <azonenberg> But i already am looking at the assembly of an inner loop that looks to be shuffling data around bytewise in a horribly inefficient fashion and thinking about how easy it would be to vectorize

23:17 <azonenberg> i swear i can't use any software now without trying to tune it lol