3 ms·

Thank you for the data point, but I do not think the issue is with rendering of the dots on screen (although I am not sure). In fact, I have done some real-time

by ptero 6y ago

Thank you for the data point, but I do not think the issue is with rendering of the dots on screen (although I am not sure). In fact, I have done some real-time, frame-by-frame video processing using OpenCV and had no issue processing 1920x1080 images in real-time at 25fps (40ms per frame), including some simple edge detection, segmentation and rendering on screen using my office workstation. Modern hardware is certainly fast enough to render dots on the screen as fast as interactive processing needs. What I suspect is taking place with Octave/Python/Julia-based tools is the additional information that needs to be handled for each plot. You need to draw axes and ticks, keep tracks of which points are displayed and obscured at at the current axes limits and update all that information every time any of those things change (reset/move/zoom, etc.). It is certainly possible to make abstraction layers that are convenient for software engineers but would not scale well with respect to the number of points that need to be plotted. Or, instead of carefully tracking each state change one could regenerate a large portion of it to make it simpler (and slower). Just a guess though.

tomsmeding 6y ago
I do think it's plotting the points that is hard: note that what I'm measuring is not rendering the image on the screen, but creating the image of the dots in the first place. Creating the image is O(number of dots) work; displaying the image is O(number of pixels) work and GPU-accelerated and peanuts. I think this because in the end, after all the axis settings and such have been determined (and drawing the axes themselves is surely not the bottleneck), all that remains is just drawing the dots in the rectangular area set out for it. My benchmark does only that part, and as I said, I'm about 50x faster than matplotlib. (C++ and not Python, so I'm not picking on matplotlib, just observing.) But anyway, if this issue is to be solved it is to be done by contributing to Octave/matplotlib etc, not by throwing around proof-of-concepts on HN. :)

by ptero 6y ago

tomsmeding 6y ago

I do think it's plotting the points that is hard: note that what I'm measuring is not rendering the image on the screen, but creating the image of the dots in the first place. Creating the image is O(number of dots) work; displaying the image is O(number of pixels) work and GPU-accelerated and peanuts. I think this because in the end, after all the axis settings and such have been determined (and drawing the axes themselves is surely not the bottleneck), all that remains is just drawing the dots in the rectangular area set out for it. My benchmark does only that part, and as I said, I'm about 50x faster than matplotlib. (C++ and not Python, so I'm not picking on matplotlib, just observing.) But anyway, if this issue is to be solved it is to be done by contributing to Octave/matplotlib etc, not by throwing around proof-of-concepts on HN. :)