 |
forums.silverfrost.com
Welcome to the Silverfrost forums
|
| View previous topic :: View next topic |
| Author |
Message |
DanRRight
Joined: 10 Mar 2008
Posts: 2925
Location: South Pole, Antarctica
|
 Posted: Sat Nov 04, 2017 10:50 pm Post subject: |
 |
|
John,
No, Silicondale had similar problem, and he mentioned the reference on Web Standard which also always was RGB not BGR. |
|
| Back to top |
|
 |
silicondale
Joined: 15 Mar 2007
Posts: 252
Location: Matlock, Derbyshire, UK
|
| Posted: Sun Nov 05, 2017 10:54 am Post subject: |
|
|
I'm now not using rgb@ for this but coding the colours directly into the standard hex format #rrggbb thus:
| Code: | write(plxy,"(a,3z2.2,a)")
1 '%pl[colour=#', ir(i),ig(i),ib(i), ',x_array]' |
as I think it was Paul who suggested - and it works just fine. Contour plot of a hill as an example -
- Steve |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8214
Location: Salford, UK
|
| Posted: Mon Nov 06, 2017 4:44 pm Post subject: |
|
|
This is to correct an earlier post in this thread relating to the [colour=#rrggbb] option that can be used in %gr, %pl and other format codes.
You can set the %pl line colour via
call winopt@("%pl[colour=#rrggbb]")
where rr is the hex value for the red component etc.
For example:
call winopt@("%pl[colour=#FF0000]")
for red etc.
| Code: | write(str,"(a,z6.6,a)") "%pl[colour=#", RGB@(255,0,0), "]"
print*, str
|
produces the output
%pl[colour=#0000FF]
which is the wrong order so it is better to use z2.2 for each component in turn. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8214
Location: Salford, UK
|
| Posted: Mon Nov 06, 2017 6:10 pm Post subject: |
|
|
| No it is not a bug. It is a correction to a previous post in this thread where I gave incorrect information. Both #rrggbb and RGB@ work correctly. My post was incorrect. |
|
| Back to top |
|
|
silicondale
Joined: 15 Mar 2007
Posts: 252
Location: Matlock, Derbyshire, UK
|
| Posted: Mon Nov 06, 2017 11:01 pm Post subject: |
|
|
Hi John. You take today's star prize. The only person in 20 years who understood 'silicondale'. 
- Steve |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8214
Location: Salford, UK
|
| Posted: Tue Nov 07, 2017 11:00 am Post subject: |
|
|
John Campbell
I have had a look at your adaptation of Dan's "surfplot program demo".
As you have noted, the displayed results are not the same for %gr and %pl.
1) %pl always uses the Microsoft GDI+ library. If [smooth4] is used with %gr then I begin to get similar output. Note that the background colour for %pl is the default (white) whilst [grey] is being used for %gr. The difference in the display particularly relates to calls to draw_line_between@. There is also another issue with draw_pixel@...
2) draw_pixel@ currently does not work when it accesses the GDI+ library (i.e. when used in a %pl callback). I have fixed this for the next release of the ClearWin+ library. Another problem is that draw_pixel@ is extremely slow for GDI+. I don't have a fix for this at the moment.
My conclusion is:
a) It's not a good idea to use draw_pixel@ in a %pl callback function because at the moment it gives the wrong result and it remains extremely slow.
b) In this kind of intensive graphics code, draw_line_between@ gives different results when accessing the Microsoft GDI+ library and when compared to the older GDI library (the basic MoveTo and LineTo functions). I have tried various smoothing modes and have not been able to create a match.
This kind of issue should only affect detailed surface plotting. There should be no problem when drawing simple lines and curves from a %pl callback function.
p.s. Edited to change from set_pixel@ to draw_pixel@ and to remove a comment about the Microsoft GDI+ library.
Last edited by PaulLaidler on Wed Nov 08, 2017 9:10 am; edited 1 time in total |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8214
Location: Salford, UK
|
| Posted: Wed Nov 08, 2017 9:06 am Post subject: |
|
|
The issue relating to draw_line_between@ in the post above has now been fixed. At the moment draw_pixel@ remains exceedingly slow when using GDI+.
The result is that the two methods (one using %gr, the other using %pl) will now produce essentially the same output. |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2925
Location: South Pole, Antarctica
|
| Posted: Wed Nov 08, 2017 8:50 pm Post subject: |
|
|
Paul
If the speeds in %pl and %gr mode are still different may be good would be to introduce GDI_off@ function which will allow surface plotting in %pl mode run with %gr speed and then when plotting done GDI_on@ will allow other plotting (lines, axis, ticks and texts) run with better quality? This will be logical with Clearwin+ ideology to control everything for better adjustments if needed. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8214
Location: Salford, UK
|
| Posted: Wed Nov 08, 2017 9:42 pm Post subject: |
|
|
John
You have to look at what is produced by the format code Z6.6. Try it and see what you get.
Dan
Unfortunately that would involve a lot of work. At some point I will have another go at getting draw_pixel@ to respond more quickly. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8214
Location: Salford, UK
|
| Posted: Wed Nov 08, 2017 9:45 pm Post subject: |
|
|
John
There are slight differences because the image size is different. That might be the only difference. |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2925
Location: South Pole, Antarctica
|
| Posted: Wed Nov 08, 2017 10:25 pm Post subject: |
|
|
Paul,
Both colors and slow speed for draw_line_between@ now fixed or just colors? |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8214
Location: Salford, UK
|
| Posted: Thu Nov 09, 2017 9:48 am Post subject: |
|
|
Dan
Only draw_pixel@ is slow (with GDI+). draw_line_between@ is (and was) OK for speed.
The slowness of drawP_pixel@ can probably be fixed in due course. It's just a case of working out the best way to interface ClearWin+ with the GDI+ library when setting single pixels. |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2925
Location: South Pole, Antarctica
|
| Posted: Thu Nov 09, 2017 7:28 pm Post subject: |
|
|
Paul and all, From start I see extreme slowness of draw_line_between@ in %PL mode.
Run the same code as i posted above (but modified to include both %GR and %PL) initially for %GR and then for %PL for example (not vice versa as %PL changes the mode) and see that with %PL it plots 20x slower. Devilry?
(there exist some another small devious bug I can not find quickly because have no time for that when in %pl mode the get_plot_point@(xx, yy, xx1, yy1) utility gets wrong xx1, yy0, yy1 plotting limits which I hope someone will find. With my other programs this works OK)
| Code: | module modSurfplotDemo
!INCLUDE <clearwin.ins> ! does NOT work
USE clrwin
integer*4 kUsePL, kUseGR
real*8 x(2),y(2), xx, yy, xx0, yy0, xx1, yy1, Progress
integer(7) handle
CONTAINS
integer function cb_Surfplot_plotting()
integer*4 ix_Window, iy_Window, ixCenter, iyCenter, ix,iy,ir, icol
real*4 xs,ys, radius, z
call get_graphical_resolution@(ix_Window, iy_Window)
xx =0;yy=0
call get_plot_point@(xx, yy, xx0, yy0)
xx =1;yy=1
call get_plot_point@(xx, yy, xx1, yy1)
If(kUseGR.eq.1) then
call USE_GDIPLUS@(0)
xx0=1; yy0=iy_Window; xx1=ix_Window; yy1=1
endif
ixCenter = (xx0+xx1)/2
iyCenter = (yy0+yy1)/2
Do ix = int(xx0+1), int(xx1-1)
if(ix/10*10.eq.ix) Progress = ix/xx1
call window_update@(Progress )
do iy = int(yy1+1), int(yy0-1)
xs = (ix-ixCenter)/(ixCenter+1.)
ys = (iy-iyCenter)/(iyCenter+1.)
radius = sqrt( xs**2 + ys**2)
z = 0.5 * (1 + cos(33.*radius)) * exp(-2.*radius**2)
ir = int(z*255)
iCol = rgb@(0,0,ir)
call DRAW_LINE_between@(ix,iy,ix,iy,iCol) ! draw_point@ (ix,iy,iCol)
end do
end Do
call UPDATE_WINDOW@(handle)
print*,'done xx0, yy0, xx1,yy1 ', xx0, yy0, xx1, yy1
cb_Surfplot_plotting = 2
end function |
Last edited by DanRRight on Thu Nov 16, 2017 3:07 am; edited 12 times in total |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2925
Location: South Pole, Antarctica
|
| Posted: Thu Nov 09, 2017 7:29 pm Post subject: |
|
|
| Code: | !..............................
Integer function SurfplotGUI ()
x(1)=0;x(2)=1
y(1)=0;y(2)=1
i = winio@('%ww%nr&') ! nr prevents slip
i=winio@('Plot Progress%ta %25br%ff&', Progress, RGB@(255,88,60))
If(kUsePL.eq.1) then
call winop@ ('%pl[native,x_array,N_GRAPHS=1]')
call winop@ ('%pl[scale=linear,link=none,symbol=7,symbol_size=3.]')
CALL winop@("%pl[dx=0.1,dy=0.1]")
! call winop@ ('%pl[scale=linear]')
call winop@ ('%pl[x_min=0.,x_max=1.,y_min=0.,y_max=1.]')
i = winio@ ('%`bg[#ffffee]&') ! Background colour
i = winio@ ('%sf&') ! return to the standard font
i = winio@ ('%ts&', 2d0) ! set the text size
i = winio@ ('%bf&') ! bold font
call winop@ ("%pl[framed,axes_pen=3,width=3,x_axis='Length (um)',y_axis='Width (um)']")
i = winio@ ('%pv&') ! allow certain controls to be re-sized under user control
i = winio@ ('%pl&',900,600,2,x,y)! ,cb_Surfplot_plotting )
else If(kUseGR.eq.1) then
i = winio@ ('%pv&') ! allow certain controls to be re-sized under user control
i = winio@('%gr[white, rgb_colours]%ff&',800,600 ) !--ADDED
endif
i = winio@ ('%ff&') ! Form feed. To move down to below any existing controls
i = winio@ ('%sf&')
i = winio@ ('%ts&', 1d0) ! text size
i = winio@ ('%cn&') ! centre text and controls
i = winio@ ('%^bt[Re-plot]&', cb_Surfplot_plotting)
i = winio@ ('%ff&')
i = winio@ ('%es&') ! close when the Escape key is pressed
i = winio@ ('%ac[Enter]&',cb_Surfplot_plotting) ! Accelerator key
i = winio@ ('%ac[Space]&',cb_Surfplot_plotting) ! Accelerator key
i = winio@ ('%hw%lw', handle, ilw)
jj = cb_Surfplot_plotting()
SurfplotGUI =2
end function SurfplotGUI
end module modSurfplotDemo
!..............................
Program Setup
use modSurfplotDemo
kUseGR=1
kUsePL=0
i=winio@('%ww Use %rb[GR]%rb[PL]&',kUseGr, kUsePL)
i=winio@('%2`ga%ff %nl&',kUseGR, kUsePL)
i=winio@ ('%ac[Enter]&', SurfplotGUI) ! Accelerator key
i=winio@ ('%ac[Ctrl+R]&', SurfplotGUI) ! Accelerator key
i=winio@('%cn%^bt[Run]%es', SurfplotGUI)
end program |
Last edited by DanRRight on Sat Nov 18, 2017 7:51 am; edited 10 times in total |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2925
Location: South Pole, Antarctica
|
| Posted: Fri Nov 10, 2017 7:38 pm Post subject: Re: |
|
|
| DanRRight wrote: | (there exist some another small devious bug I can not find quickly because have no time for that when in %pl mode the get_plot_point@(xx, yy, xx1, yy1) utility gets wrong xx1, yy0, yy1 plotting limits which I hope someone will find. With my other programs this works OK)
|
I found and fixed this error (not the slowness of plotting under %PL, this needs addressing by Paul since John-S confirmed the slowness) and now all plots nicely. Why these two lines are not an equivalent in Fortran which is counter-intuitive? I initially used | Code: | | If(kUseGR.eq.1) xx0=1; yy0=iy_Window; xx1=ix_Window; yy1=1 |
which intended to set when kUseGR = 1 ALL these variables in the line, not just first one, while to do that Fortran requires | Code: | If(kUseGR.eq.1) then; xx0=1; yy0=iy_Window; xx1=ix_Window; yy1=1; endif
|
Last edited by DanRRight on Fri Nov 10, 2017 8:10 pm; edited 1 time in total |
|
| Back to top |
|
|
|
|
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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
