forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

painting a %pl region

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1968
Location: Sydney

PostPosted: Wed Nov 01, 2017 4:35 am    Post subject: painting a %pl region Reply with quote

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5437
Location: Salford, UK

PostPosted: Wed Nov 01, 2017 8:06 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1968
Location: Sydney

PostPosted: Wed Nov 01, 2017 1:37 pm    Post subject: Reply with quote

Paul,

Am I using the wrong approach to paint into %pl ?
There is a problem with the colour produced.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1864
Location: South Pole, Antarctica

PostPosted: Wed Nov 01, 2017 3:07 pm    Post subject: Reply with quote

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 Smile


Last edited by DanRRight on Wed Nov 01, 2017 3:27 pm; edited 6 times in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5437
Location: Salford, UK

PostPosted: Wed Nov 01, 2017 3:12 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1968
Location: Sydney

PostPosted: Thu Nov 02, 2017 2:50 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5437
Location: Salford, UK

PostPosted: Thu Nov 02, 2017 9:02 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1968
Location: Sydney

PostPosted: Thu Nov 02, 2017 11:57 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 1968
Location: Sydney

PostPosted: Mon Nov 06, 2017 3:51 am    Post subject: Reply with quote

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)
Code:
  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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5437
Location: Salford, UK

PostPosted: Mon Nov 06, 2017 8:42 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group