forums.silverfrost.com

[silicondale]

Dan - your second line has y1=1, while the first line has yy1=1

cheers !

- Steve

[DanRRight]

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

[DanRRight]

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?

[PaulLaidler]

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.

[PaulLaidler]

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.

[DanRRight]

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@

[PaulLaidler]

If you mean "turn off" for %pl, then it's not that simple. The native %pl is written using GDI+.

[DanRRight]

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...

[PaulLaidler]

I have made a note that this needs investigating.

In the meantime the use of draw_pixel@ in a %pl callback should be avoided.

[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.

[jalih]

[PaulLaidler]

Thank you. I have tried that approach.

[PaulLaidler]

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).

[DanRRight]

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

[PaulLaidler]

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.