Following on from Dan's example of painting a %pl region, I thought I would give comparative examples of painting a %pl and %gr region (outside the Native %pl thread).

These examples show:
# the comparative time for painting %pl vs %gr
# problems with the colour for painting %pl

My preferred approach is to create an integer*4 colour array and use draw_line_between, rather than direct manipulation of the graphics surface (which should be better) or multiple calls to update each pixel.
I have found problems when mixing direct manipulation with user_resize and full_mouse_input, so resorted to the approach I have posted.

The advantage of the approach I have posted is that for many updates of the graphics screen (eg with hidden line removal), this approach has a single final paint to the graphics device. There is a separation of the stages of preparing the graphics and painting.
This example also demonstrates the relative timing for generation and painting ( which is a problem with this approach for %pl )
They work in 32 and /64, although /64 %gr exits badly ?

Any suggestions are welcomed, especially if there are better approaches to the apparent problem when painting %pl region.

The relative "slowness" of %pl against %gr should not be a problem for most users. With %pl you can draw graphs with large numbers of points in a window that can be resized. As you resize, the graph is continuously redrawn and there is barely a flicker.

If it becomes a serious problem then there may be a fix that can be applied within ClearWin+.

The native %pl always uses GDI+ (even when smoothness is not requested). The result is that the (x,y) data has to be copied to a temporary array and it will probably be the memory allocation for this array (off the main heap) that is making the difference.

Paul,
Right now with first attempts of making surfplots 20 seconds is OK, but in the future to plot small size 800x600 surfplot for 20 seconds is definitely waaaay too slow. Forget about resizing with such speeds. I use %gr approach for 20 years and it works fast so I do not notice its speed. And even in 3D OpenGL plotting and resizing full size 4K images is faster. In which platform are you developing all this software? Is this is your own C/C++ ? Looks like /TIMING is not available there

Last edited by DanRRight on Wed Nov 01, 2017 3:27 pm; edited 6 times in total

I applied a patch to the %pl test and it showed no errors with the supplied iCol value, but the display is definitely wrong. See check_iCol.
If you select "Surfplot" 4 times you will see each colour test, which indicates the iCol values are not corrupted; The test should be 1=red, 2=green, 3=blue; 0=red-blue.

I posted these examples, as the painting approach of using draw_line_between@ works very well for speeding up the graphics I do, with typically greater repeating of RGB values or a background colour, ie higher % line calls > fewer calls.
What I find with %gr is fewer calls then final call UPDATE_WINDOW@ is fastest approach.
Could %pl be updating the screen driver more often than final UPDATE_WINDOW@ ?

I changed draw_point@ to draw_line_between@ but there was no change in the display.
I then changed draw_line_between@ to:
do kx = lx,ix
call draw_point@ (kx,iy,iCol)
end do
This resulted in the display now being similar to Dan's original plot, but with rgb plotted as bgr.

So it appears there could be problems with both draw_line_between@ and rgb > bgr.