View previous topic :: View next topic |
Author |
Message |
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sat Nov 11, 2017 3:58 am Post subject: |
|
|
here's the plot I get with your corrected code Dan ....
(once again Win7 32bit v8.1+dlls14)
I note that there needs to be a mod to the colouring algorithm to get the same pattern 'squeex�zed into' the %pl frame (currently it's just a sub-set of the %gr one (with only 4/3 rings h/v and non-symmetric)
the scales are again inconc�stent imo.
I see that in this case %pl is 'intelligent' (or is it chance) and leaves what would be crowded/overlapping every othertick labels on x-axis.
The question is, why not on Y-axis which looks very 'crowded'.
imo the algorithm for doing that should be different on Y axis than x axis.
Also, would it be better to treat the non-labelled ticks as 'minor ticks' and give them a shorter length which would lead to even better readability ?
Eventually there could be a good mod to intelligently introduce �unlabelled secondary ticks automatically or to allow user-specified secondary tick marks via options/parameters.
One for the wish list once the other niggling anomalies/bugs already well documented are eventually sorted. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Sat Nov 11, 2017 4:14 pm Post subject: |
|
|
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?
Code: | If(kUseGR.eq.1) xx0=1; yy0=iy_Window; xx1=ix_Window; yy1=1 |
Last edited by DanRRight on Sat Nov 11, 2017 5:13 pm; edited 1 time in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Sat Nov 11, 2017 4:50 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sat Nov 11, 2017 6:08 pm Post subject: |
|
|
Quote: | has been fixed by extending the length of lines in the Fortran code by one pixel |
??? now I'm completely lost, unless I've missed something earlier ???
I thought the plot was corrected by putting the missing endif in, what's all this 1 pixe in, 1 pixel out ( do we have to shake it all about ) business ? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Sat Nov 11, 2017 7:12 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Sat Nov 11, 2017 9:45 pm Post subject: |
|
|
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@
Last edited by DanRRight on Sat Nov 11, 2017 9:54 pm; edited 1 time in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Sat Nov 11, 2017 9:52 pm Post subject: |
|
|
If you mean "turn off" for %pl, then it's not that simple. The native %pl is written using GDI+. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Sat Nov 11, 2017 9:59 pm Post subject: |
|
|
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... |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Sun Nov 12, 2017 10:18 am Post subject: |
|
|
I have made a note that this needs investigating.
In the meantime the use of draw_pixel@ in a %pl callback should be avoided. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Tue Nov 14, 2017 4:36 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Tue Nov 14, 2017 8:49 pm Post subject: |
|
|
Dan, sorry for the late reply, yes I noticed the slowing down of the %gr when launched after %pl.
One other thing I noticed was that the %pl doesn't draw the picture progressively in bands from left to right like %gr does, it just suddenly appears the whole picture at the end of processing.
I don't know if that is normal or relevant to the slowness.
Also, when using %gr the second time, it only draws progressively about 1/5th of the picture then stops and then the rest appears at the end |
|
Back to top |
|
|
jalih
Joined: 30 Jul 2012 Posts: 196
|
Posted: Wed Nov 15, 2017 6:48 am Post subject: Re: |
|
|
PaulLaidler wrote: | 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? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Wed Nov 15, 2017 8:13 am Post subject: |
|
|
Thank you. I have tried that approach. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Wed Nov 15, 2017 11:31 am Post subject: |
|
|
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). |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Wed Nov 15, 2017 9:58 pm Post subject: |
|
|
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
Code: | 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. |
|
Back to top |
|
|
|