 |
forums.silverfrost.com
Welcome to the Silverfrost forums
|
| View previous topic :: View next topic |
| Author |
Message |
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7924
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: 7924
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 |
|
|
John-Silver
Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley
|
| Posted: Wed Nov 08, 2017 7:39 pm Post subject: |
|
|
| Quote: | | 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. |
I didn't understand that Paul, becasue it must have been a bug,not in RGB@ but %pl in the way it took the components givn by RGB@ ?
| Quote: | | the same or not quite the same, and if the latter what are the differences ? |
'essentially' - does that mean exactly the same or quasi-exactly , and if the latter what could the small differences be ?
To resolve the draw_point@ problem could it maybe be possible to use draw_line_between@ between 2 identical points with a zero length ? Just a stupid thought. |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2815
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: 7924
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: 7924
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: 2815
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: 7924
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: 2815
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: 2815
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 |
|
|
John-Silver
Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley
|
| Posted: Fri Nov 10, 2017 2:51 am Post subject: |
|
|
Dan ,
I ran your last code above with the latest I have Persov8.1+dlls14
For %gr .....
as you say it runs pretty swiftly
Then subsequently with %pl ...
It looks to me like the problem with getting the right data from get_plot_point@ might be related to the margins (as it was with the log-log problems thaat I think it was Ken had previously. Strange how it seems to pick up the lh margin but not top/bottom/rh ones.
This bug concerns me a bit because if one wants to override the %pl axes titles with one's own plot_characters generated ones then all the margins and I think the tick labels text parameters need to be known be known in order to calculate the position for the draw_characters text positioning )as we've seen the totles still have a coupl of bugs related to positiioning.
One last thing which really bugs me is why is the format of the end tick labels on the x-axis different from the rest (integer not real)!!!! For me annoying in the extreme )
Finally, I have noted that re-sizing works seamlessly for the %gr case but for %pl I just get a resized blank axes (This is consistent with other observed similar problems with re-sizing a Na %pl window in other previous examples posted. |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2815
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 |
|
|
silicondale
Joined: 15 Mar 2007
Posts: 243
Location: Matlock, Derbyshire, UK
|
| Posted: Fri Nov 10, 2017 7:56 pm Post subject: |
|
|
Dan - your second line has y1=1, while the first line has yy1=1
cheers !
- Steve |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2815
Location: South Pole, Antarctica
|
| Posted: Fri Nov 10, 2017 8:11 pm Post subject: |
|
|
Steve,
Oops, that was a damn devilry typo, i do not know how i make them even copy-and-pasting, i fixed it. No, the problem i was talking about is of different matter: why | Code: | | If(kUseGR.eq.1) xx0=1; yy0=iy_Window; xx1=ix_Window; yy1=1 |
sets only first variable and ignores all other in the same line, which is counterintuitive and extremely error-prone. It is doing like that
| Code: | If(kUseGR.eq.1) xx0=1
yy0=iy_Window
xx1=ix_Window
yy1=1 |
instead of
| Code: | If(kUseGR.eq.1) then
xx0=1
yy0=iy_Window
xx1=ix_Window
yy1=1
endif |
|
|
| Back to top |
|
|
John-Silver
Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley
|
| Posted: Sat Nov 11, 2017 2:29 am Post subject: |
|
|
Dan, your multi-line code on one line is just that, several individual lines of code, as you've shown when you 'expanded' it.
There's no 'endif' so all the code isn't blocked within the IF, as it is in the second example. Only the first coneition is subject to the IF. |
|
| 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
