#689 XWIN driver resizing ruins the plot:

[GregJung]

This is a long-standing problem I believe; if there is an earlier version of either
plplot or of GDL for which it doesn't show, please let me know.
By building and running the plplot examples you can show there should be no issue (plplot-5.11.1)
in resizing a multicolor plot. Plots made through GDL, however, are not robust to resizing. Using the
attached file to define a basic set of colors, !tekcolors,

@tekcolors
tekc=!tekcolors & names = tag_names(tekc)
plot,findgen(120),background=88 ; not black so you can see the plot after resizing
for k=0,15 do oplot,7k+indgen(7),7k+indgen(7),thick=3,color=tekc.(k)
for k=0,15 do xyouts,4+7k,1+7k, chars=2,chart=2,names[k]

Now move the plot by its edges. ok so far, right?
Now resize the plot. all of the writing goes black.

[GregJung]

For the windows driver wingcc the resizing will destroy any and all oplot, xyouts,
plots calls made after the initial PLOT. By calling eop() after these calls, the plot
modifications are included in the new refresh procedure:

--- a/f/gdl-0.9.6/src/plotting.hpp
+++ b/f/gdl/src/plotting.hpp
@@ -300,8 +300,11 @@ DStructGDL *GetMapAsMapStructureKeyword(EnvT *e, bool &externalMap);
       call_plplot(e, actStream);

       post_call(e, actStream);
-      if (isDB) actStream->eop(); else actStream->flush();
-      if (isDB) actStream->UnSetDoubleBuffering();
+// change to where eop() is always called. //GVJ 2016-02-07
+      actStream->eop();
+//      if (isDB) actStream->eop(); else actStream->flush();
+//      if (isDB) actStream->UnSetDoubleBuffering();
+      if (isDB) actStream->UnSetDoubleBuffering(); else actStream->flush();
       actStream->Update();
     } // }}}
   };

This seems to fix the biggest problem in windows' wingcc.c,
where the backup bitmap copy is triggered via eop(). No harmful side effects have been
observed yet for the xwin driver.

repeating the plot in literal text mode:

@tekcolors
tekc=!tekcolors & names = tag_names(tekc)
plot,findgen(120),background=88 
; not black so you can see the plot after resizing
for k=0,15 do oplot,7*k+indgen(7),7*k+indgen(7),thick=3,color=tekc.(k)
for k=0,15 do xyouts,4+7*k,1+7*k, chars=2,chart=2,names[k]

Attached is the windows (wingcc, plplot5.11.1) result after resizing
The resizing has lost the background color (now black) and there is only a single scaling factor
(so the plot runs out of the resized window) But the OPLOT and XYOUTS elements have remained
because of the continual actStream->eop() calls.

[giloo]

Hello,

I believe this is going over currents GDL specifications. IDL plots made with traditional plot commands (PLOT, OPLOT, etc) are not put to scale on window resizing and must be replayed. So wrt the initial goals of GDL (traditional IDL compatibility for continuous free use of existing IDL-based scientific code) I would argue that the plot should be erased on window resizing.

It is true that plplot permits a replay of the plplots commands sent to the plplot stream in case of resizing (mind: not keeping shapes) . This is what plplot's examples show. But GDL does not use plplot for images, and plplot's "replay" will not remember the changes of palette (LOADCT) made during the plot (especially since plplot does know about truecolor palettes). So automatic replay will always be somewhat "false".

Resizing has been "authorized" in GDL, using this plplot feature, but it works only in the most simple cases: DEVICE,DECOMPOSED=0 + no images + no change of palette. And the symbols and character shapes are modified.

I think that by overloading HasDoubleBuffering() and HasSafeDoubleBuffering() in gdlwinstream.hpp to return true will do the trick. But changing the code of plotting.hpp is not an option.

[GregJung]

I agree the insertion of ->eop() in plotting.hpp was more intrusive than required.
The call to Update() is currently a noop so I was able to put
void Update() { this->eop();} in gdlwinstream.hpp, and that has the same effiect,
which however fails when plotting over the bitmaps in test_tv.

[Sylwester Arabas]

Greg, Gilles, what is the conclusion here? Is there anything to move to github as a new issue?
Thanks for help,
S.

[GregJung]

No real issue here - so old that it is probably not reproducable.

On Tue, Apr 10, 2018 at 1:48 PM, Sylwester Arabas slayoo@users.sourceforge.net wrote:

Greg, Gilles, what is the conclusion here? Is there anything to move to
github as a new issue?
Thanks for help,
S.

---

• [bugs:#689] https://sourceforge.net/p/gnudatalanguage/bugs/689/ XWIN
  driver resizing ruins the plot: *

Status: open
Group: v1.0 (example)
Created: Sun Feb 07, 2016 05:21 AM UTC by GregJung
Last Updated: Sun Feb 07, 2016 08:48 PM UTC
Owner: nobody
Attachments:

• tekcolors.pro
  https://sourceforge.net/p/gnudatalanguage/bugs/689/attachment/tekcolors.pro
  (400 Bytes; text/plain)

This is a long-standing problem I believe; if there is an earlier version
of either
plplot or of GDL for which it doesn't show, please let me know.
By building and running the plplot examples you can show there should be
no issue (plplot-5.11.1)
in resizing a multicolor plot. Plots made through GDL, however, are not
robust to resizing. Using the
attached file to define a basic set of colors, !tekcolors,

@tekcolors
tekc=!tekcolors & names = tag_names(tekc)
plot,findgen(120),background=88 ; not black so you can see the plot after
resizing
for k=0,15 do oplot,7k+indgen(7),7k+indgen(7),thick=3,color=tekc.(k)
for k=0,15 do xyouts,4+7k,1+7k, chars=2,chart=2,names[k]

Now move the plot by its edges. ok so far, right?
Now resize the plot. all of the writing goes black.

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/gnudatalanguage/bugs/689/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Sylwester Arabas]

Closing then, thanks