Should there be other curves with the other connect mechanisms like finite that test with a np.nan value?

Implementing "pairs" already allows the user to plot arbitrary line segments and strips.
If we ignore details like join and miter, every additional mode could be reduced to GL_LINES aka pairs.

It shouldn't be difficult by taking reference from the following:

Alternatively for "finite" mode, line strips could be extracted for multiple calls to GL_LINE_STRIP:

However, I don't think it's a particularly useful thing to implement if the only purpose is to support more of the API of PlotCurveItem. PlotCurveItem already has too many extras baked in like histogram and fill that don't play well with non-finites.

However, I don't think it's a particularly useful thing to implement if the only purpose is to support more of the API of PlotCurveItem. PlotCurveItem already has too many extras baked in like histogram and fill that don't play well with non-finites.

I'm in complete agreement here. The histogram and fill should either be removed from PlotCurveItem or we create another GraphicsItem (PlotLineItem?) that is a bit more primitive in the functionality, but that's a separate discussion.

Should the library emit warning (or raise an Exception) when using openGL with PlotCurveItem where if a user tries to do a histogram or a fill?

A better solution is to only call paintGL for supported modes.
The script in #2878 now "works" whether enableExperimental is True or False.

Hi @pijyoi , this looks great!

This does look like a good opportunity to rethink the architecture we now have with PlotCurveItem and PlotDataItem. It does not seem necessary to replicate everything that PlotCurveItem now does.

From my perspective it might be reasonable for a revised PlotCurveItem to take data

• that is known-good (e.g. no non-finites)
• does not require any modification (e.g. no step plots, no log mode)

That would reasonably move the task of preprocessing for NaNs to PlotDataItem. That could include processing all data into 'pairs', which would indeed be a very generic solution that should work for almost everything.

One thing I wanted to add here is that the data I encounter might have very long "good" segments (all finite), then a short section where a failure generates NaN, followed by another "good" segment. If the fastest path is still the equivalent of 'finite', 'skip-tests' mode, then being able to plot multiple long segments of known-good data might be interesting. PlotDataItem would need to figure out what mode to use.

As an additional comment/question, OpenGL is probably very happy to render the filled shapes used with fillLevel or by the FillBetweenItem. Is there a particular arrangement of code that avoids transferring the same curve data to the GPU twice?

That would reasonably move the task of preprocessing for NaNs to PlotDataItem. That could include processing all data into 'pairs', which would indeed be a very generic solution that should work for almost everything.

One thing I wanted to add here is that the data I encounter might have very long "good" segments (all finite), then a short section where a failure generates NaN, followed by another "good" segment. If the fastest path is still the equivalent of 'finite', 'skip-tests' mode, then being able to plot multiple long segments of known-good data might be interesting. PlotDataItem would need to figure out what mode to use.

I think a good middle ground would be a hypothetical PlotLineItem that accepts a (not too large) list of "good" segments.
This would satisfy the current connect="finite" mode as well as users wanting to plot a great many line segments using a single GraphicsItem.
The connect="all" mode would just be a list of one segment.
This would map to multiple calls to QPainter.drawPolyline / glDrawArrays(GL_LINE_STRIP)

Although this would also support connect="pairs", it would incur a large overhead. (Nothing would stop a user from doing it, however) So "pairs" and "ndarray" mode could instead map to QPainter.drawLines / glDrawArrays(GL_LINES).

As an additional comment/question, OpenGL is probably very happy to render the filled shapes used with fillLevel or by the FillBetweenItem. Is there a particular arrangement of code that avoids transferring the same curve data to the GPU twice?

The filling API of pyqtgraph does not require the shape to be closed. Take for example the filling of the area under a sine curve. Even for the current pyqtgraph QGraphicsView implementation, this requires two separate calls:

1. QPainter.fillPath to flood fill the "enclosed" area (pyqtgraph library does the closing)
2. QPainter.drawPath to draw the sine curve

For OpenGL (caveat, my knowledge of OpenGL is limited), filling the area would require generating the vertices for the triangle strip that covers the area to be filled. So it would in any case be two different sets of vertices to be sent to the GPU. One for the curve to be drawn using GL_LINE_STRIP and the other to be drawn using GL_TRIANGLE_STRIP.

I think implementing a theoretical PlotLineItem so we can be aggressive about API breakage is a great idea. Also gives us the opportunity to use QPainter.drawPolyline which the benchmark seems to indicate it works better.

The one question I have is, would it make sense for any of the downsampling stuff to occur at that level, or should that remain in the PlotDataItem/higher level objects to implement?

@pijyoi , thank you for your reply!

Your suggestions look very reasonable to me, I have no further comments. I am certain that if you encounter a way to streamline the OpenGL data transfer, you'll be the very first to jump on it. :)

@j9ac9k,

I think the downsampling would want to be placed at the same level where transforms like log mode are handled.

• for the heavier transforms, it makes sense to have the option to downsample first, THEN transform.
• either of these actions has to inspect the dataset and generates insights into e.g. the existance of non-finites if it runs. This should help choose the best drawing mode, for example. (See PlotDataItem's 'connect=auto' mode.) Having this information in one place may make things a little more elegant than having cascaded checks through the different levels.

I think the downsampling would want to be placed at the same level where transforms like log mode are handled.

I agree that the transforms and downsamples should stick together. In what order that happens, I think there is an argument to be made on how non-linear the transform is; but that's a discussion for another PR.

The next concern I have right now is involving "thick" lines. I don't think this needs to be addressed in this specific PR, but I'd like to at least bring it up. The issue right now is the use of glLineWidth(width_values), The supported glLineWidth range of values to my understanding is limited by the OpenGL driver, and in some drivers it is limited to just 1 pixel, and even if the desired thickness is within the reported range, there are issues with it not working. There is a small github repo that points this out and proposes some alternatives (of various complexities).

https://github.com/mhalber/Lines?tab=readme-ov-file#why

Looking at some of the alternatives listed, the geometry shader seems like a good place to inject some functionality here, but that requires OpenGL 3.2. I'd be curious to hear anyone else's thoughts.

Looking at some of the alternatives listed, the geometry shader seems like a good place to inject some functionality here, but that requires OpenGL 3.2. I'd be curious to hear anyone else's thoughts.

Actually it uses a number of OpenGL 4.5 API (https://github.com/mhalber/Lines/blob/f20b5e2509d98e5d8e273d9730036ec5aecaa02d/geometry_shader_lines.h#L203-L214)

Looking at some of the alternatives listed, the geometry shader seems like a good place to inject some functionality here, but that requires OpenGL 3.2. I'd be curious to hear anyone else's thoughts.

Actually it uses a number of OpenGL 4.5 API (https://github.com/mhalber/Lines/blob/f20b5e2509d98e5d8e273d9730036ec5aecaa02d/geometry_shader_lines.h#L203-L214)

Oh yeah, OpenGL 4.5 API is a non-starter, anything above 4.1 won't work , alternative being QRhi, but that's a whole other thing.

@pijyoi, thank you so much for the fantastic work on pyqtgraph performance. This is an excellent addition like so many that came before.

From my perspective it might be reasonable for a revised PlotCurveItem to take data

* that is known-good (e.g. no non-finites) 
* does not require any modification (e.g. no step plots, no log mode)

I am all for rethinking the API and separating concerns, especially where it leads to better performance. However I don't think this PR is the right place to start that work, mostly because (you can hear my experience with vispy here) OpenGL is really weird in some ways, and it tends to guide one toward strange architectural contortions that otherwise make life more difficult.

As an example of that point, there's an even more interesting performance target which is to write GPU shaders that perform all of the data processing. Ideally, we should send only the raw data as provided by the user to the GPU and the rest happens there--filtering for finite values, transformations (both linear and nonlinear), construction of new geometry like triangle strips or histogram steps, etc. In that case it may not be necessary to have a simplifed PlotLineItem if, in the end, PlotCurveItem is able to handle all types of data efficiently.

I think I prefer a somewhat different approach (that we have discussed before), using a PlotData class that encapsulates raw x,y data plus a set of filters / transforms and then allows the user of that data (PlotDataItem, PlotCurveItem, etc) to specify the result that is needed. For example, if PlotCurveItem wants strips of nan-free data, then PlotData can provide that in the most efficient way. If there is a ScatterPlotItem that uses the same PlotData instance, then when it asks for nan-free values, the PlotData instance can return previously cached results. If you wanted to implement all or part of this in GPU, then you could simply request PlotData give you raw or partially-processed data, plus the extra metadata needed to complete the processing in a GPU shader.

The issue right now is the use of glLineWidth(width_values), The supported glLineWidth range of values to my
understanding is limited by the OpenGL driver, and in some drivers it is limited to just 1 pixel,

This is indeed a major issue, and one that I don't recommend taking on lightly. For now, just having the high performance of 1px-width lines covers the vast majority of high performance use cases. If you ever want to go further than that, then let's have a long talk about the architecture of vispy and how similar concepts could be implemented here.

I have implemented the origin shifting suggestion in #2417.
This does fix the obvious issue demonstrated in #2020 (comment)

This necessitates extra computation in that the data has to be converted to double precision first to perform the translation before finally converting it back to single precision for OpenGL vertex buffers.
But correctness over speed, right?

Modified the MouseSelection example to demonstrate the quantization effect if origin shift not applied:

Thanks for this PR @pijyoi

Getting a more robust OpenGL implementation throughout the library would be such an amazing improvement. Also having some implementations done makes it easier for contributors to attempt to add OpenGL support for other parts too.

I hope we can revisit the enableExperimental setting that this is being kept behind, but that's a decision for a future PR.

non-working: if QPen is created with a non-solid brush.
#3068 (comment)