Neil Pate

@dadreamerthis sounds like the perfect use case for some low level OS API trickery, like reading the value directly from memory. If only there was someone who was good at stuff like this 😉

I think the answer is no, but I ask anyway. Does anyone know if it is possible to access an event or some other thing that returns the colour that is currently being "selected" by the mouse cursor when this colour picker widget is open? I mean getting a new value when the user moves their mouse around while the widget is open and has focus? I suspect this is all deep in C++ land but would love to be wrong here.

Frame rate is now at 100 FPS, time to stop optimising 🙂 2022-10-08 21-49-45.mkv

Plot twist... it turns out that the MoveBlock technique is quicker when replacing long-ish rows, but for smaller chunks of pixles the naive replace an element at a time is actually faster. I just used the worst case scenario in the benchmark, but have realised this is not actually sensible when rendering things made of smaller triangles (and hence smaller line segments). This is what I am rendering, it has close to 20k vertices.

Nope. The use case in this situation is just to learn 🙂

Unfortunately I cannot actually do this optimisation as normally the length of the line, and pixel colour will differ every single call. Well, actually the colour will stay the same for some number of calls, but the line length will normally change. In my benchmark VI I just used a worst case scenario of a line filling the whole row. Your MoveBlock2 method still seems faster, thanks! I will see how it affects the performance of my actual application.

Thanks everyone, I really appreciate the help. I will take a look over the weekend at the suggestions.

Windows for now, but the point of the exercise is to implement as much as possible from source.

Ah, that explains the crash when opening in 2015. Thanks!

Hi everyone, I am trying to wring as much performance as possible out of a single VI I have created. It is part of a rendering application and will be called many-many times per second. In essence it just draws a horizontal line in a 2D array of pixels. I have four techniques implemented (3 work, 1 crashes LabVIEW). Is anyone up for the challenge of trying to get it any faster? I have attached version in 2015 and 2022. I developed in 2022 and back-saved, but for some reason just opening the code in my 2015 LV instance crashes (but it opens fine in 2021). Raster 2022Q3.zip Raster 2015.zip

Not quite sure what you mean by this.

@ShaunR you are missing a bit

Sorry to hear about your troubles, this does happen. One thing worth checking (as this has bit me many times) is dead/broken/old code in Diagram Disable Structures. Symptoms are like you noticed, running in the IDE is fine, but often the builder will just not cope. Often the dead code in a DDS is old and contains invalid enums or old versions of classes etc. Really funky things seem to happen.

It seems there was no Discord server for LabVIEW. Well, that has all changed. DM if you are interested in joining. It is open to anyone interested, but I don't want to post the link as I have no idea how to deal with spam/bots!

Sure, but I still don't see the point as you could just keep the variant in the feedback node (and this VI is accessible by all processes) . What does adding it to a single element queue do?

I guess there is much more code and it makes sense when looking at the bigger picture, but with this snippet I don't really get this. Why bother with making a single element queue the reference of which your store in the feedback node. Why not just store the variant itself? (using the feedback node?)

What you have made looks great, and I absolutely commend your effort. But, I think the area of the shaded part of the Venn diagram that consists of people willing to pay for LabVIEW and want to get into Deep Learning using a new and paid for toolkit is a number approaching machine epsilon. NI has abandoned Academic institutions and is introducing a new licensing model that is predatory and harmful to the long term viability of LabVIEW. It breaks my heart...

Sometimes some weird locking of classes/libraries can occur if you dont perfectly close all opened resources. Totally off-topic, why do you have a reference to the class and also the class object itself? I see you don't actually do anything with this cluster so it could be throw-away code, was just curious about your use case.

I definitely can echo what @JKSHsaid. Several years ago I implemented a data dashboard with WebVI tech (in NXG) and the overall experience was so painful I will never try it again.

Remaking an image editor sounds like a fun weekend project if there is beer involved. But I suspect the end result would be throwaway code! I totally agree with you pushing back on this requirement, it sounds like the potential for massive feature creep. Sorry, I do not know any .net or similar toolkits to embed into a LabVIEW application. Maybe there is some javascript implementation you can embed using a web-browser frame thingy (like https://paint.js.org/) ?

😂 The glass is definitely half-full

I guess this was the extremely ambitiously engineered greening of National Instruments into NI.

I completely empathise!

OK, I did not get that impression at all.