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.

John

https://www.dropbox.com/s/qepaf5ka2vwp4hm/gr_plot2.f95?dl=0 https://www.dropbox.com/s/ar8h8h5i24mb19v/pl_plot.f95?dl=0

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,

Am I using the wrong approach to paint into %pl ? There is a problem with the colour produced.

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 😃

John

Your method looks OK to me.

Most of the time goes in draw_point@. The GDI+ implementation of this in ClearWin+ is very slow at the moment.

Paul,

There is definitely a problem with the colour being displayed in %pl.

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.

https://www.dropbox.com/s/ar8h8h5i24mb19v/pl_plot.f95?dl=0

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@ ?

John

John

Is it draw_point@ that is not working?

It is extremely slow when used with the native %pl because GDI+ is being used.

If it also gives the wrong colour then there are two good reasons for avoiding this approach until I have had a chance to look at the problem.

Paul,

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.

Paul,

I am puzzled by the use of RGB@ in %pl, based on the examples I posted.

Perhaps the use of draw_line_between@ or draw_point@ in a %pl region, as it is used in a %gr region is not supported.

Could there be a historical inconsistency in the use of colour values in %pl ?

I have no problems using rgb@ for %gr.

I assumed rgb@ is an in-line function, so the following use could be a useful extension. Could it be converted to an intrinsic function ? INTEGER, PARAMETER :: RED = rgb@ (255,0,0)

  integer rgb@, icol, red, green, blue
  integer, parameter :: zRED   = z'0000FF'
  integer, parameter :: zGREEN = z'00FF00'
  integer, parameter :: zBLUE  = z'FF0000'
!
  red   = rgb@ (255,0,0)
  green = rgb@ (0,255,0)
  blue  = rgb@ (0,0,255)  

  write (*,fmt='(3z10)') red, green, blue
  write (*,fmt='(3z10)') zred, zgreen, zblue
  end

John

John

I think that the main issue is that the native %pl uses GDI+ together with the fact that there are one or two GDI+ issues to fix relating to '%gr' functions.

I have made a note that this needs linvestigation.