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 

Native %pl
Goto page Previous  1, 2, 3 ... 15, 16, 17, 18  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
John-Silver



Joined: 30 Jul 2013
Posts: 603

PostPosted: Sat Nov 11, 2017 3:58 am    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



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

PostPosted: Sat Nov 11, 2017 4:14 pm    Post subject: Reply with quote

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


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

PostPosted: Sat Nov 11, 2017 4:50 pm    Post subject: Reply with quote

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
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 603

PostPosted: Sat Nov 11, 2017 6:08 pm    Post subject: Reply with quote

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


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

PostPosted: Sat Nov 11, 2017 7:12 pm    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



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

PostPosted: Sat Nov 11, 2017 9:45 pm    Post subject: Reply with quote

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


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

PostPosted: Sat Nov 11, 2017 9:52 pm    Post subject: Reply with quote

If you mean "turn off" for %pl, then it's not that simple. The native %pl is written using GDI+.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Sat Nov 11, 2017 9:59 pm    Post subject: Reply with quote

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


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

PostPosted: Sun Nov 12, 2017 10:18 am    Post subject: Reply with quote

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


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

PostPosted: Tue Nov 14, 2017 4:36 pm    Post subject: Reply with quote

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
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 603

PostPosted: Tue Nov 14, 2017 8:49 pm    Post subject: Reply with quote

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
View user's profile Send private message
jalih



Joined: 30 Jul 2012
Posts: 188

PostPosted: Wed Nov 15, 2017 6:48 am    Post subject: Re: Reply with quote

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


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

PostPosted: Wed Nov 15, 2017 8:13 am    Post subject: Reply with quote

Thank you. I have tried that approach.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Wed Nov 15, 2017 11:31 am    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



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

PostPosted: Wed Nov 15, 2017 9:58 pm    Post subject: Reply with quote

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@ Smile ] 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
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
Goto page Previous  1, 2, 3 ... 15, 16, 17, 18  Next
Page 16 of 18

 
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