Welcome to our forums
Paul, Both colors and slow speed for draw_line_between@ now fixed or just colors?
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.
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)
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
!..............................
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
Quoted from DanRRight (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 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 If(kUseGR.eq.1) then; xx0=1; yy0=iy_Window; xx1=ix_Window; yy1=1; endif
Dan - your second line has y1=1, while the first line has yy1=1
cheers !
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 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
If(kUseGR.eq.1) xx0=1
yy0=iy_Window
xx1=ix_Window
yy1=1
instead of
If(kUseGR.eq.1) then
xx0=1
yy0=iy_Window
xx1=ix_Window
yy1=1
endif
Now it is symmetric, I fixed the code, this was my fault. Other deficiencies with crowded tic numbering (Ken mentioned open access subroutine to do universal numbering almost a year ago, the ideal number of major tics is between 5 and 12, anything else is a crime to the eye and has to be set manually) , minor/major tics and slowness of %pl are valid, hope Paul will mark them to fix
As to the IF construct in Fortran, interesting how other languages treat this line, also controlling only first statement xx0=1, or all statements in the line?
If(kUseGR.eq.1) xx0=1; yy0=iy_Window; xx1=ix_Window; yy1=1
I am a bit concerned that the %pl plot has been fixed by extending the length of lines in the Fortran code by one pixel. It means that, when you get the next set of DLLs it will be wrong again because this was what was required internally to get a match. Also this is required to make Microsoft GDI calls compatible with GDI+ calls so the internal fix is necessary.
John
I am not sure about the details but the code to draw the image should be the same in %pl (using GDI+) as in %gr (using GDI). I have fixed ClearWin+ so that (in the next release) the two approaches will draw the same number of points for a given line. This is not the case with the current release, where, on each line, one of the end points is missing for %pl (GDI+).
Normally this is not a problem because lines are usually joined one to another and the problem is hidden in the join.
And have you all also noticed that after running %pl the %gr becomes slow ?
Also if you resize the %gr plotting area with the mouse the get_graphical_resolution@(ix_Window, iy_Window) does not work correctly because %gr does not plot resized image? I removed the commented line in the code, now it has the Re-plot button
In %pl mode resizing works OK. Looks like we still need additional function turn_off_GDIplus@
If you mean 'turn off' for %pl, then it's not that simple. The native %pl is written using GDI+.
I mean that somehow %pl interferes with the %gr after %pl was called. This is visible by abrupt slowness of %gr as if it became running under %pl but the %pl is not used! Please use latest version, I corrected the last code above on page 15
Do you see speed difference in %gr with my code after you called %pl first?
Use %gr - plots fast, hit Esc when done. Use %pl - plots slow, hit Esc. Use %gr again- plots slow ! Devilry...
I have made a note that this needs investigating.
In the meantime the use of draw_pixel@ in a %pl callback should be avoided.
Despite lengthy investigation, draw_point@ remains show when accessing the GDI+ library (and hence when called from a %pl callback function).
Unfortunately this issue remains unresolved.
Quoted from PaulLaidler Despite lengthy investigation, draw_point@ remains show when accessing the GDI+ library (and hence when called from a %pl callback function).
Unfortunately this issue remains unresolved.
Use LockBits/UnlockBits and manipulate data directly?
Thank you. I have tried that approach.
Dan and John
The native %pl makes a call to USE_GDIPLUS@(1) and this state remains active for a following %gr. You will notice the difference when extensive use is made of draw_point@. In other situations it probably makes no noticeable difference.
I am not sure at the moment whether this should be treated as a ClearWin+ design fault or indeed if anything can be done about it.
You could also try calling USE_GDIPLUS@(0) in your %pl callback that calls draw_point@. It should overcome the slowness but does it produce the correct display?
I can guess the follow up question but I will wait and see if I am right! (Perhaps I should learn how to use emoticons).
Thanks, Paul, your guess was right.
/* Though Paul clearly afraid to touch this devilry code [ I judge that by that the code does not use draw_point@, it uses draw_line_between@ 😃 ] he was right, the USE_GDIPLUS@(0) placed here
If(kUseGR.eq.1) then
call USE_GDIPLUS@(0)
xx0=1; yy0=iy_Window; xx1=ix_Window; yy1=1
endif
works to stop slowness of %gr after using %pl. And that is exactly the switcher off of the GDI+ I missed and was asking for in the previous postings
The only what's left to find is the reason of 20x slowness of draw_line_between@ in the %pl mode.
Suggestion of a temporal solution to consider for developers: essentially, after creating the X and Y axis frame with the ticks and labels we may not need the GDI+ for surface plotting. So if switch it off and allow the pass of commands like draw_line_between@ the goal of fast surfplotting could be achieved.
John, behavior of your code is exactly as of mine one. By the way, I already made beautiful plotting utility using it surpassing (except for too crowded Y axis numbering which was necessary to photoshop afterwards) the one on page 1 of this thread,
my co-workers were awed seeing usual boring code output numbers in their magnificent beauty, will show it some day. It does not use the whole (X x Y) area of the graph so the plotting with GDI+ is essentially instant.
John
I am not sure if this is what you want but there are already options [dx=fval] and [dy=fval] to specify the preferred interval between tick marks.