plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Bug fix to plbuf.c

[Phil R. <p.d...@gm...>]

I agree that option 2 seems less "hacky" - it is directly addressing
the problem with a clear solution rather than trying to bend the
existing interface and further muddy the interface between the core
and driver code.

The only disadvantage of 2 is that things will break (compile or run
time problems?) for driver that do not implement the new interface.

How many drivers are we talking about and would this effect
noninteractive drivers? The interactive drivers I can remember right
now are
wxWidgets
Qt
X
Windows
Tcl

What breakages will occur to them while we propagate this through?

Phil

On 14 June 2015 at 03:29, Jim Dishaw <ji...@di...> wrote:
>
> On Jun 13, 2015, at 2:11 PM, Jim Dishaw <ji...@di...> wrote:
>
>
> On Jun 13, 2015, at 1:13 PM, Phil Rosenberg <p.d...@gm...> wrote:
>
> Hmmm
> Then hmmmm some more
> Followed by an ummm or two.
>
> As you say Jim, clearly things are more complicated than I realised. I'm not
> sure what the requirements really are here now. Now you have brought this up
> I can imagine the issues associated with entering the message loop after an
> eop.
>
> In terms of dealing with it, I'm not at my computer right now, but I think
> probably a bop_forced function which forces a bop irrespective of where we
> are in the page cycle would work. But I'm not sure if that might have some
> potential subtle effects elsewhere so it is a bit of a hack really. Perhaps
> instead it would be better to assess what is being done in a bop and ensure
> those actions end up in the buffer so a bop event is not required.
>
>
> I think that is a good approach for reasons beyond this issue, but a BOP and
> EOP of some type is still required to support the drivers adequately (e.g
> double buffering, printing from the windows API).
>
> The solution I'm going to test is one where the driver does not enter into a
> wait for input state on a redraw event from the callback.
>
>
> I came up with two solutions, one of which I tested.
>
> Solution 1 (Tested)
>
> Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so
> now an EOP is written to the buffer.  This will cause an EOP to be generated
> when the plot buffer is replayed.  I like the symmetry of having an EOP in
> the buffer to match the BOP.
>
> Drivers will be responsible for determining if a “wait for user input”
> should be performed during an EOP.  For the wingdi driver I track the state
> of a “page_state” that changes outside of the BOP/EOP calls.
>
> This solution feels a bit kludgy, but it works.
>
> Solution 2
>
> Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so
> now an EOP is written to the buffer.  This will cause an EOP to be generated
> when the plot buffer is replayed.
>
> Add a new driver function to the dispatch table (e.g. pl_wait) that calls
> the "wait for user input between pages" function.
>
> Remove from all drivers the “wait for input” from the EOP handler.
>
> The PLplot core library will call the wait for input between pages function
> (if not null).
>
> This solution strikes me as a more elegant solution because the logic for
> deciding about the wait for input is one spot.
>
> Regardless of the solution, some changes to the drivers will be required.
> Solution 2 will touch all the drivers (at a minimum to add a NULL to the
> dispatch table).  Solution 1 adds code to the drivers while solution 2
> removes some code from the drivers.
>
>
> Phil
> ________________________________
> From: Jim Dishaw
> Sent: ‎13/‎06/‎2015 17:55
> To: Alan W. Irwin
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Bug fix to plbuf.c
>
>
> On Jun 13, 2015, at 12:03 PM, Jim Dishaw <ji...@di...> wrote:
>
>
> On Jun 11, 2015, at 12:29 AM, Jim Dishaw <ji...@di...> wrote:
>
>
> On Jun 10, 2015, at 11:30 PM, Alan W. Irwin <ir...@be...>
> wrote:
>
>  <snip>
>
> Just to confirm that I just now played a lot with resizing of
>
> examples/c/x01c -dev xwin
>
> for 5.10.0, 5.11.0, and git master tip (including your recent commit),
> and I found no specific string issues for any of those cases.  So it
> appears hard (at least with this example) to demonstrate a rendering
> bug due to this issue that you just fixed, but your fix seems logical
> to me (now) and certainly does not introduce any bad string rendering
> that I can spot.
>
> However, when doing those checks I did notice other resizing issues
> that do need to be addressed.
>
> 1. As a resize is occurring (typically by dragging one edge or one
> corner of the GUI to make the whole thing smaller or larger) sometimes
> the displayed GUI is a scaled plot and sometimes it is black (which is
> OK).  But on some occasions when I stop resizing (by releasing the
> mouse button) the result remains black for 5.11.0 and the master tip
> version (which is not OK).  But 5.10.0 is fine in this regard. So this
> issue is a regression introduced into PLplot between 5.10.0 and 5.11.0
> and probably due to the flurry of changes you and Phil made in plbuf
> before we released 5.11.0.
>
>
>
> Please verify the good result for 5.10.0 and bad result for 5.11.0,
> git bisect to figure out what commit has caused the issue, and then
> make the appropriate plbuf fix to get rid of this regression.
>
>
> I think this problem is the plP_eop() that was inserted in the
> plRemakePlot() to make sure the BOP would perform as expected.  For the GUI
> drivers this will trigger another wait for input, which ends up blocking
> redraw messages.  I will verify by using git bisect.
>
>
> I ran git bisect and the regression was introduced in the commit
> 1e402417c1f3e87c391fe428f936153c2a10e8cc
>
> Author: Phil Rosenberg <p.d...@gm...>
> Date:   Fri Feb 27 17:12:03 2015 +0000
>
>     Fixed bug in rdbuf_di.
>
>     Save cursubpage on replot
>     call plP_eop() on replot which ensures that the first plP_bop() call
> actually does something.
>
> If I comment out the plP_eop() that was added to plbuf.c in that commit, the
> xwin driver does not exhibit the problematic behavior.  I will investigate
> further on working on a patch.  I know why it is causing a problem, but it
> isn’t obvious to me how it gets to that point.
>
>
> I found the cause of the problem and the plP_eop() is not acting in a way
> that neither Phil nor I expected.  Phil put the plP_eop() in to make sure
> that the BOP will do something and I thought that will always to lead to the
> keypress bug.  In reality the plP_eop() does something only half the time.
>
> 1) Plot starts
> 2) At BOP, the page_status is set to AT_BOP
> 3) While drawing, the page_status is set to DRAWING
> 4) At EOP, the page_status is set to AT_EOP  (the EOP is not put into the
> buffer)
> 5) The driver enters into a loop waiting for messages
> 6) Driver receives a resize message
> 7) plRemakePlot is called
> 8) plRemakPlot() calls plP_eop()
> 9) plP_eop() does nothing because it exits immediately because the
> page_status is AT_EOP
> 10) The plot buffer is replayed
> 11) At BOP, the page_status is set to AT_BOP
> 12) While drawing, the page_status is set to DRAWING
> 13) No EOP is generated because it is not in the buffer, thus the
> page_status is unchanged
> 14) Control returns the message loop
> 15) Another resize message is received
> 16) plRemakePlot is called
> 17) plRemakePlot() calls plP_eop()
> 18) plP_eop() does not exit immediately this time because page_state is
> DRAWING
> 19) plP_eop() calls the driver EOP handler
> 20) The driver enters into a new loop waiting for messages
> 21) User has to do an action (e.g. keypress) to exit the new message loop.
> This blocks many messages because the windowing system still considers the
> window to be processing a resize.
> 22) Once the new message loop exits, the driver EOP handler exits.
> 23) Goto step 10.
>
> Just putting the EOP into the plot buffer won’t fix the problem because a
> new message loop will be called, which will block messages.
>
> I agree with Phil’s point about the need to call plP_eop().  Some drivers
> may need the EOP handler to work correctly (e.g. double buffering). The way
> the code is structured, the plP_eop() is only doing something 50% of the
> time.
>
> I’m not sure the best way to fix this.  I think the interactive GUI drivers
> might need to be modified to check if they are already waiting.  One thing
> that makes this tricky is the strip chart function.  As it is currently
> written, it does not generate an EOP until the end.  Thus, it cannot be
> resized while plotting.  Plus, when resized, the entire strip chart is
> replayed (though I see Phil has made some commits so wxWidgets might be
> smarter).
>
> I’m going to experiment on some different approaches and see what works
> best.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>

Re: [Plplot-devel] Bug fix to plbuf.c

[Jim D. <ji...@di...>]

> On Jun 13, 2015, at 2:11 PM, Jim Dishaw <ji...@di...> wrote:
> 
> 
> On Jun 13, 2015, at 1:13 PM, Phil Rosenberg <p.d...@gm... <mailto:p.d...@gm...>> wrote:
> 
>> Hmmm
>> Then hmmmm some more
>> Followed by an ummm or two.
>> 
>> As you say Jim, clearly things are more complicated than I realised. I'm not sure what the requirements really are here now. Now you have brought this up I can imagine the issues associated with entering the message loop after an eop.
>> 
>> In terms of dealing with it, I'm not at my computer right now, but I think probably a bop_forced function which forces a bop irrespective of where we are in the page cycle would work. But I'm not sure if that might have some potential subtle effects elsewhere so it is a bit of a hack really. Perhaps instead it would be better to assess what is being done in a bop and ensure those actions end up in the buffer so a bop event is not required.
>> 
> 
> I think that is a good approach for reasons beyond this issue, but a BOP and EOP of some type is still required to support the drivers adequately (e.g double buffering, printing from the windows API).  
> 
> The solution I'm going to test is one where the driver does not enter into a wait for input state on a redraw event from the callback. 

I came up with two solutions, one of which I tested.

Solution 1 (Tested)

Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so now an EOP is written to the buffer.  This will cause an EOP to be generated when the plot buffer is replayed.  I like the symmetry of having an EOP in the buffer to match the BOP.

Drivers will be responsible for determining if a “wait for user input” should be performed during an EOP.  For the wingdi driver I track the state of a “page_state” that changes outside of the BOP/EOP calls.

This solution feels a bit kludgy, but it works.

Solution 2

Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so now an EOP is written to the buffer.  This will cause an EOP to be generated when the plot buffer is replayed. 

Add a new driver function to the dispatch table (e.g. pl_wait) that calls the "wait for user input between pages" function.

Remove from all drivers the “wait for input” from the EOP handler.

The PLplot core library will call the wait for input between pages function (if not null).

This solution strikes me as a more elegant solution because the logic for deciding about the wait for input is one spot.

Regardless of the solution, some changes to the drivers will be required.  Solution 2 will touch all the drivers (at a minimum to add a NULL to the dispatch table).  Solution 1 adds code to the drivers while solution 2 removes some code from the drivers.

> 
>> Phil
>> From: Jim Dishaw <mailto:ji...@di...>
>> Sent: ‎13/‎06/‎2015 17:55
>> To: Alan W. Irwin <mailto:ir...@be...>
>> Cc: PLplot development list <mailto:Plp...@li...>
>> Subject: Re: [Plplot-devel] Bug fix to plbuf.c
>> 
>> 
>>> On Jun 13, 2015, at 12:03 PM, Jim Dishaw <ji...@di... <mailto:ji...@di...>> wrote:
>>> 
>>> 
>>>> On Jun 11, 2015, at 12:29 AM, Jim Dishaw <ji...@di... <mailto:ji...@di...>> wrote:
>>>> 
>>>>> 
>>>>> On Jun 10, 2015, at 11:30 PM, Alan W. Irwin <ir...@be... <mailto:ir...@be...>> wrote:
>>>  <snip>
>>>>> Just to confirm that I just now played a lot with resizing of
>>>>> 
>>>>> examples/c/x01c -dev xwin
>>>>> 
>>>>> for 5.10.0, 5.11.0, and git master tip (including your recent commit),
>>>>> and I found no specific string issues for any of those cases.  So it
>>>>> appears hard (at least with this example) to demonstrate a rendering
>>>>> bug due to this issue that you just fixed, but your fix seems logical
>>>>> to me (now) and certainly does not introduce any bad string rendering
>>>>> that I can spot.
>>>>> 
>>>>> However, when doing those checks I did notice other resizing issues
>>>>> that do need to be addressed.
>>>>> 
>>>>> 1. As a resize is occurring (typically by dragging one edge or one
>>>>> corner of the GUI to make the whole thing smaller or larger) sometimes
>>>>> the displayed GUI is a scaled plot and sometimes it is black (which is
>>>>> OK).  But on some occasions when I stop resizing (by releasing the
>>>>> mouse button) the result remains black for 5.11.0 and the master tip
>>>>> version (which is not OK).  But 5.10.0 is fine in this regard. So this
>>>>> issue is a regression introduced into PLplot between 5.10.0 and 5.11.0
>>>>> and probably due to the flurry of changes you and Phil made in plbuf
>>>>> before we released 5.11.0.
>>>> 
>>>>> 
>>>>> Please verify the good result for 5.10.0 and bad result for 5.11.0,
>>>>> git bisect to figure out what commit has caused the issue, and then
>>>>> make the appropriate plbuf fix to get rid of this regression.
>>>>> 
>>>> 
>>>> I think this problem is the plP_eop() that was inserted in the plRemakePlot() to make sure the BOP would perform as expected.  For the GUI drivers this will trigger another wait for input, which ends up blocking redraw messages.  I will verify by using git bisect.
>>> 
>>> I ran git bisect and the regression was introduced in the commit 1e402417c1f3e87c391fe428f936153c2a10e8cc
>>> 
>>> Author: Phil Rosenberg <p.d...@gm... <mailto:p.d...@gm...>>
>>> Date:   Fri Feb 27 17:12:03 2015 +0000
>>> 
>>>     Fixed bug in rdbuf_di.
>>>     
>>>     Save cursubpage on replot
>>>     call plP_eop() on replot which ensures that the first plP_bop() call actually does something.
>>> 
>>> If I comment out the plP_eop() that was added to plbuf.c in that commit, the xwin driver does not exhibit the problematic behavior.  I will investigate further on working on a patch.  I know why it is causing a problem, but it isn’t obvious to me how it gets to that point.
>>> 
>> 
>> I found the cause of the problem and the plP_eop() is not acting in a way that neither Phil nor I expected.  Phil put the plP_eop() in to make sure that the BOP will do something and I thought that will always to lead to the keypress bug.  In reality the plP_eop() does something only half the time.
>> 
>> 1) Plot starts
>> 2) At BOP, the page_status is set to AT_BOP
>> 3) While drawing, the page_status is set to DRAWING
>> 4) At EOP, the page_status is set to AT_EOP  (the EOP is not put into the buffer)
>> 5) The driver enters into a loop waiting for messages
>> 6) Driver receives a resize message
>> 7) plRemakePlot is called
>> 8) plRemakPlot() calls plP_eop()
>> 9) plP_eop() does nothing because it exits immediately because the page_status is AT_EOP
>> 10) The plot buffer is replayed
>> 11) At BOP, the page_status is set to AT_BOP
>> 12) While drawing, the page_status is set to DRAWING
>> 13) No EOP is generated because it is not in the buffer, thus the page_status is unchanged
>> 14) Control returns the message loop
>> 15) Another resize message is received
>> 16) plRemakePlot is called
>> 17) plRemakePlot() calls plP_eop()
>> 18) plP_eop() does not exit immediately this time because page_state is DRAWING
>> 19) plP_eop() calls the driver EOP handler
>> 20) The driver enters into a new loop waiting for messages
>> 21) User has to do an action (e.g. keypress) to exit the new message loop.  This blocks many messages because the windowing system still considers the window to be processing a resize.
>> 22) Once the new message loop exits, the driver EOP handler exits.
>> 23) Goto step 10.
>> 
>> Just putting the EOP into the plot buffer won’t fix the problem because a new message loop will be called, which will block messages.  
>> 
>> I agree with Phil’s point about the need to call plP_eop().  Some drivers may need the EOP handler to work correctly (e.g. double buffering). The way the code is structured, the plP_eop() is only doing something 50% of the time. 
>> 
>> I’m not sure the best way to fix this.  I think the interactive GUI drivers might need to be modified to check if they are already waiting.  One thing that makes this tricky is the strip chart function.  As it is currently written, it does not generate an EOP until the end.  Thus, it cannot be resized while plotting.  Plus, when resized, the entire strip chart is replayed (though I see Phil has made some commits so wxWidgets might be smarter).
>> 
>> I’m going to experiment on some different approaches and see what works best.
>> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li... <mailto:Plp...@li...>
> https://lists.sourceforge.net/lists/listinfo/plplot-devel <https://lists.sourceforge.net/lists/listinfo/plplot-devel>

Re: [Plplot-devel] Bug fix to plbuf.c

[Alan W. I. <ir...@be...>]

On 2015-06-13 17:15-0400 Jim Dishaw wrote:

>
>
>> On Jun 13, 2015, at 3:25 PM, Phil Rosenberg <p.d...@gm...> wrote:
>>
>> Okay, well if you need any help or testing let me know.
>>
>> Something that I haven't seen up to now (but maybe I never looked hard enough) is a spec sheet for how to write a driver, I.e. What events should a buffer deal with and in what way. Given the effort I've just been through with rewriting wxWidgets driver and what you are going through with the windows driver, perhaps we should write it, and then we can refer to it and if we wish to tidy the core-driver interface in the future it will be a useful reference.
>>
>
> Absolutely. Writing a driver should not be this hard. I think getting things documented might clear some of the problems between what we think is happening and what is really happening.

"Yes please" on some documentation for how to write a driver.  I am no
expert in this aspect of PLplot, but I do have two "overview" points to
make.

1. Device drivers for PLplot have been advertised as easy to write so let's make that so
with improved documentation.

2. My gut feeling is that the overview (aside from the X specifics)
for the xwin device would make a good template for an interactive
device driver.  The reason I say that is that was the interactive
device driver that got all the TLC in the early PLplot history. For
example, it handles calls to plxormod and plGetCursor properly for
example 20 while the other interactive device drivers currently do
not. So aside from treatment of text (which is way out of date for the
xwin device), I think it would be worth your while to study the design
overview of the xwin device to see if it might help you to document
the general design of interactive device drivers.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Bug fix to plbuf.c

[Jim D. <ji...@di...>]

> On Jun 13, 2015, at 3:25 PM, Phil Rosenberg <p.d...@gm...> wrote:
> 
> Okay, well if you need any help or testing let me know.
> 
> Something that I haven't seen up to now (but maybe I never looked hard enough) is a spec sheet for how to write a driver, I.e. What events should a buffer deal with and in what way. Given the effort I've just been through with rewriting wxWidgets driver and what you are going through with the windows driver, perhaps we should write it, and then we can refer to it and if we wish to tidy the core-driver interface in the future it will be a useful reference.
> 

Absolutely. Writing a driver should not be this hard. I think getting things documented might clear some of the problems between what we think is happening and what is really happening. 

> Phil
> From: Jim Dishaw
> Sent: ‎13/‎06/‎2015 19:11
> To: Phil Rosenberg
> Cc: Alan W. Irwin; PLplot development list
> Subject: Re: [Plplot-devel] Bug fix to plbuf.c
> 
> 
>> On Jun 13, 2015, at 1:13 PM, Phil Rosenberg <p.d...@gm...> wrote:
>> 
>> Hmmm
>> Then hmmmm some more
>> Followed by an ummm or two.
>> 
>> As you say Jim, clearly things are more complicated than I realised. I'm not sure what the requirements really are here now. Now you have brought this up I can imagine the issues associated with entering the message loop after an eop.
>> 
>> In terms of dealing with it, I'm not at my computer right now, but I think probably a bop_forced function which forces a bop irrespective of where we are in the page cycle would work. But I'm not sure if that might have some potential subtle effects elsewhere so it is a bit of a hack really. Perhaps instead it would be better to assess what is being done in a bop and ensure those actions end up in the buffer so a bop event is not required.
> 
> I think that is a good approach for reasons beyond this issue, but a BOP and EOP of some type is still required to support the drivers adequately (e.g double buffering, printing from the windows API).  
> 
> The solution I'm going to test is one where the driver does not enter into a wait for input state on a redraw event from the callback. 
> 
>> Phil
>> From: Jim Dishaw
>> Sent: ‎13/‎06/‎2015 17:55
>> To: Alan W. Irwin
>> Cc: PLplot development list
>> Subject: Re: [Plplot-devel] Bug fix to plbuf.c
>> 
>> 
>>>> On Jun 13, 2015, at 12:03 PM, Jim Dishaw <ji...@di...> wrote:
>>>> 
>>>> 
>>>>> On Jun 11, 2015, at 12:29 AM, Jim Dishaw <ji...@di...> wrote:
>>>>> 
>>>>> 
>>>>> On Jun 10, 2015, at 11:30 PM, Alan W. Irwin <ir...@be...> wrote:
>>>  <snip>
>>>>> Just to confirm that I just now played a lot with resizing of
>>>>> 
>>>>> examples/c/x01c -dev xwin
>>>>> 
>>>>> for 5.10.0, 5.11.0, and git master tip (including your recent commit),
>>>>> and I found no specific string issues for any of those cases.  So it
>>>>> appears hard (at least with this example) to demonstrate a rendering
>>>>> bug due to this issue that you just fixed, but your fix seems logical
>>>>> to me (now) and certainly does not introduce any bad string rendering
>>>>> that I can spot.
>>>>> 
>>>>> However, when doing those checks I did notice other resizing issues
>>>>> that do need to be addressed.
>>>>> 
>>>>> 1. As a resize is occurring (typically by dragging one edge or one
>>>>> corner of the GUI to make the whole thing smaller or larger) sometimes
>>>>> the displayed GUI is a scaled plot and sometimes it is black (which is
>>>>> OK).  But on some occasions when I stop resizing (by releasing the
>>>>> mouse button) the result remains black for 5.11.0 and the master tip
>>>>> version (which is not OK).  But 5.10.0 is fine in this regard. So this
>>>>> issue is a regression introduced into PLplot between 5.10.0 and 5.11.0
>>>>> and probably due to the flurry of changes you and Phil made in plbuf
>>>>> before we released 5.11.0.
>>>> 
>>>>> 
>>>>> Please verify the good result for 5.10.0 and bad result for 5.11.0,
>>>>> git bisect to figure out what commit has caused the issue, and then
>>>>> make the appropriate plbuf fix to get rid of this regression.
>>>> 
>>>> I think this problem is the plP_eop() that was inserted in the plRemakePlot() to make sure the BOP would perform as expected.  For the GUI drivers this will trigger another wait for input, which ends up blocking redraw messages.  I will verify by using git bisect.
>>> 
>>> I ran git bisect and the regression was introduced in the commit 1e402417c1f3e87c391fe428f936153c2a10e8cc
>>> 
>>> Author: Phil Rosenberg <p.d...@gm...>
>>> Date:   Fri Feb 27 17:12:03 2015 +0000
>>> 
>>>     Fixed bug in rdbuf_di.
>>>     
>>>     Save cursubpage on replot
>>>     call plP_eop() on replot which ensures that the first plP_bop() call actually does something.
>>> 
>>> If I comment out the plP_eop() that was added to plbuf.c in that commit, the xwin driver does not exhibit the problematic behavior.  I will investigate further on working on a patch.  I know why it is causing a problem, but it isn’t obvious to me how it gets to that point.
>> 
>> I found the cause of the problem and the plP_eop() is not acting in a way that neither Phil nor I expected.  Phil put the plP_eop() in to make sure that the BOP will do something and I thought that will always to lead to the keypress bug.  In reality the plP_eop() does something only half the time.
>> 
>> 1) Plot starts
>> 2) At BOP, the page_status is set to AT_BOP
>> 3) While drawing, the page_status is set to DRAWING
>> 4) At EOP, the page_status is set to AT_EOP  (the EOP is not put into the buffer)
>> 5) The driver enters into a loop waiting for messages
>> 6) Driver receives a resize message
>> 7) plRemakePlot is called
>> 8) plRemakPlot() calls plP_eop()
>> 9) plP_eop() does nothing because it exits immediately because the page_status is AT_EOP
>> 10) The plot buffer is replayed
>> 11) At BOP, the page_status is set to AT_BOP
>> 12) While drawing, the page_status is set to DRAWING
>> 13) No EOP is generated because it is not in the buffer, thus the page_status is unchanged
>> 14) Control returns the message loop
>> 15) Another resize message is received
>> 16) plRemakePlot is called
>> 17) plRemakePlot() calls plP_eop()
>> 18) plP_eop() does not exit immediately this time because page_state is DRAWING
>> 19) plP_eop() calls the driver EOP handler
>> 20) The driver enters into a new loop waiting for messages
>> 21) User has to do an action (e.g. keypress) to exit the new message loop.  This blocks many messages because the windowing system still considers the window to be processing a resize.
>> 22) Once the new message loop exits, the driver EOP handler exits.
>> 23) Goto step 10.
>> 
>> Just putting the EOP into the plot buffer won’t fix the problem because a new message loop will be called, which will block messages.  
>> 
>> I agree with Phil’s point about the need to call plP_eop().  Some drivers may need the EOP handler to work correctly (e.g. double buffering). The way the code is structured, the plP_eop() is only doing something 50% of the time. 
>> 
>> I’m not sure the best way to fix this.  I think the interactive GUI drivers might need to be modified to check if they are already waiting.  One thing that makes this tricky is the strip chart function.  As it is currently written, it does not generate an EOP until the end.  Thus, it cannot be resized while plotting.  Plus, when resized, the entire strip chart is replayed (though I see Phil has made some commits so wxWidgets might be smarter).
>> 
>> I’m going to experiment on some different approaches and see what works best.
>> 

Re: [Plplot-devel] Bug fix to plbuf.c

[Phil R. <p.d...@gm...>]

Okay, well if you need any help or testing let me know.

Something that I haven't seen up to now (but maybe I never looked hard enough) is a spec sheet for how to write a driver, I.e. What events should a buffer deal with and in what way. Given the effort I've just been through with rewriting wxWidgets driver and what you are going through with the windows driver, perhaps we should write it, and then we can refer to it and if we wish to tidy the core-driver interface in the future it will be a useful reference.

Phil

-----Original Message-----
From: "Jim Dishaw" <ji...@di...>
Sent: ‎13/‎06/‎2015 19:11
To: "Phil Rosenberg" <p.d...@gm...>
Cc: "Alan W. Irwin" <ir...@be...>; "PLplot development list" <Plp...@li...>
Subject: Re: [Plplot-devel] Bug fix to plbuf.c



On Jun 13, 2015, at 1:13 PM, Phil Rosenberg <p.d...@gm...> wrote:


Hmmm
Then hmmmm some more
Followed by an ummm or two.

As you say Jim, clearly things are more complicated than I realised. I'm not sure what the requirements really are here now. Now you have brought this up I can imagine the issues associated with entering the message loop after an eop.

In terms of dealing with it, I'm not at my computer right now, but I think probably a bop_forced function which forces a bop irrespective of where we are in the page cycle would work. But I'm not sure if that might have some potential subtle effects elsewhere so it is a bit of a hack really. Perhaps instead it would be better to assess what is being done in a bop and ensure those actions end up in the buffer so a bop event is not required.




I think that is a good approach for reasons beyond this issue, but a BOP and EOP of some type is still required to support the drivers adequately (e.g double buffering, printing from the windows API).  


The solution I'm going to test is one where the driver does not enter into a wait for input state on a redraw event from the callback. 


Phil


From: Jim Dishaw
Sent: ‎13/‎06/‎2015 17:55
To: Alan W. Irwin
Cc: PLplot development list
Subject: Re: [Plplot-devel] Bug fix to plbuf.c




On Jun 13, 2015, at 12:03 PM, Jim Dishaw <ji...@di...> wrote:




On Jun 11, 2015, at 12:29 AM, Jim Dishaw <ji...@di...> wrote:



On Jun 10, 2015, at 11:30 PM, Alan W. Irwin <ir...@be...> wrote:
 <snip>

Just to confirm that I just now played a lot with resizing of

examples/c/x01c -dev xwin

for 5.10.0, 5.11.0, and git master tip (including your recent commit),
and I found no specific string issues for any of those cases.  So it
appears hard (at least with this example) to demonstrate a rendering
bug due to this issue that you just fixed, but your fix seems logical
to me (now) and certainly does not introduce any bad string rendering
that I can spot.

However, when doing those checks I did notice other resizing issues
that do need to be addressed.

1. As a resize is occurring (typically by dragging one edge or one
corner of the GUI to make the whole thing smaller or larger) sometimes
the displayed GUI is a scaled plot and sometimes it is black (which is
OK).  But on some occasions when I stop resizing (by releasing the
mouse button) the result remains black for 5.11.0 and the master tip
version (which is not OK).  But 5.10.0 is fine in this regard. So this
issue is a regression introduced into PLplot between 5.10.0 and 5.11.0
and probably due to the flurry of changes you and Phil made in plbuf
before we released 5.11.0.




Please verify the good result for 5.10.0 and bad result for 5.11.0,
git bisect to figure out what commit has caused the issue, and then
make the appropriate plbuf fix to get rid of this regression.



I think this problem is the plP_eop() that was inserted in the plRemakePlot() to make sure the BOP would perform as expected.  For the GUI drivers this will trigger another wait for input, which ends up blocking redraw messages.  I will verify by using git bisect.



I ran git bisect and the regression was introduced in the commit 1e402417c1f3e87c391fe428f936153c2a10e8cc


Author: Phil Rosenberg <p.d...@gm...>
Date:   Fri Feb 27 17:12:03 2015 +0000


    Fixed bug in rdbuf_di.
    
    Save cursubpage on replot
    call plP_eop() on replot which ensures that the first plP_bop() call actually does something.


If I comment out the plP_eop() that was added to plbuf.c in that commit, the xwin driver does not exhibit the problematic behavior.  I will investigate further on working on a patch.  I know why it is causing a problem, but it isn’t obvious to me how it gets to that point.




I found the cause of the problem and the plP_eop() is not acting in a way that neither Phil nor I expected.  Phil put the plP_eop() in to make sure that the BOP will do something and I thought that will always to lead to the keypress bug.  In reality the plP_eop() does something only half the time.


1) Plot starts
2) At BOP, the page_status is set to AT_BOP
3) While drawing, the page_status is set to DRAWING
4) At EOP, the page_status is set to AT_EOP  (the EOP is not put into the buffer)
5) The driver enters into a loop waiting for messages
6) Driver receives a resize message
7) plRemakePlot is called
8) plRemakPlot() calls plP_eop()
9) plP_eop() does nothing because it exits immediately because the page_status is AT_EOP
10) The plot buffer is replayed
11) At BOP, the page_status is set to AT_BOP
12) While drawing, the page_status is set to DRAWING
13) No EOP is generated because it is not in the buffer, thus the page_status is unchanged
14) Control returns the message loop
15) Another resize message is received
16) plRemakePlot is called
17) plRemakePlot() calls plP_eop()
18) plP_eop() does not exit immediately this time because page_state is DRAWING
19) plP_eop() calls the driver EOP handler
20) The driver enters into a new loop waiting for messages
21) User has to do an action (e.g. keypress) to exit the new message loop.  This blocks many messages because the windowing system still considers the window to be processing a resize.
22) Once the new message loop exits, the driver EOP handler exits.
23) Goto step 10.


Just putting the EOP into the plot buffer won’t fix the problem because a new message loop will be called, which will block messages.  


I agree with Phil’s point about the need to call plP_eop().  Some drivers may need the EOP handler to work correctly (e.g. double buffering). The way the code is structured, the plP_eop() is only doing something 50% of the time. 


I’m not sure the best way to fix this.  I think the interactive GUI drivers might need to be modified to check if they are already waiting.  One thing that makes this tricky is the strip chart function.  As it is currently written, it does not generate an EOP until the end.  Thus, it cannot be resized while plotting.  Plus, when resized, the entire strip chart is replayed (though I see Phil has made some commits so wxWidgets might be smarter).


I’m going to experiment on some different approaches and see what works best.

Re: [Plplot-devel] Bug fix to plbuf.c

[Jim D. <ji...@di...>]

> On Jun 13, 2015, at 1:13 PM, Phil Rosenberg <p.d...@gm...> wrote:
> 
> Hmmm
> Then hmmmm some more
> Followed by an ummm or two.
> 
> As you say Jim, clearly things are more complicated than I realised. I'm not sure what the requirements really are here now. Now you have brought this up I can imagine the issues associated with entering the message loop after an eop.
> 
> In terms of dealing with it, I'm not at my computer right now, but I think probably a bop_forced function which forces a bop irrespective of where we are in the page cycle would work. But I'm not sure if that might have some potential subtle effects elsewhere so it is a bit of a hack really. Perhaps instead it would be better to assess what is being done in a bop and ensure those actions end up in the buffer so a bop event is not required.
> 

I think that is a good approach for reasons beyond this issue, but a BOP and EOP of some type is still required to support the drivers adequately (e.g double buffering, printing from the windows API).  

The solution I'm going to test is one where the driver does not enter into a wait for input state on a redraw event from the callback. 

> Phil
> From: Jim Dishaw
> Sent: ‎13/‎06/‎2015 17:55
> To: Alan W. Irwin
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Bug fix to plbuf.c
> 
> 
>>> On Jun 13, 2015, at 12:03 PM, Jim Dishaw <ji...@di...> wrote:
>>> 
>>> 
>>>> On Jun 11, 2015, at 12:29 AM, Jim Dishaw <ji...@di...> wrote:
>>>> 
>>>> 
>>>> On Jun 10, 2015, at 11:30 PM, Alan W. Irwin <ir...@be...> wrote:
>>  <snip>
>>>> Just to confirm that I just now played a lot with resizing of
>>>> 
>>>> examples/c/x01c -dev xwin
>>>> 
>>>> for 5.10.0, 5.11.0, and git master tip (including your recent commit),
>>>> and I found no specific string issues for any of those cases.  So it
>>>> appears hard (at least with this example) to demonstrate a rendering
>>>> bug due to this issue that you just fixed, but your fix seems logical
>>>> to me (now) and certainly does not introduce any bad string rendering
>>>> that I can spot.
>>>> 
>>>> However, when doing those checks I did notice other resizing issues
>>>> that do need to be addressed.
>>>> 
>>>> 1. As a resize is occurring (typically by dragging one edge or one
>>>> corner of the GUI to make the whole thing smaller or larger) sometimes
>>>> the displayed GUI is a scaled plot and sometimes it is black (which is
>>>> OK).  But on some occasions when I stop resizing (by releasing the
>>>> mouse button) the result remains black for 5.11.0 and the master tip
>>>> version (which is not OK).  But 5.10.0 is fine in this regard. So this
>>>> issue is a regression introduced into PLplot between 5.10.0 and 5.11.0
>>>> and probably due to the flurry of changes you and Phil made in plbuf
>>>> before we released 5.11.0.
>>> 
>>>> 
>>>> Please verify the good result for 5.10.0 and bad result for 5.11.0,
>>>> git bisect to figure out what commit has caused the issue, and then
>>>> make the appropriate plbuf fix to get rid of this regression.
>>> 
>>> I think this problem is the plP_eop() that was inserted in the plRemakePlot() to make sure the BOP would perform as expected.  For the GUI drivers this will trigger another wait for input, which ends up blocking redraw messages.  I will verify by using git bisect.
>> 
>> I ran git bisect and the regression was introduced in the commit 1e402417c1f3e87c391fe428f936153c2a10e8cc
>> 
>> Author: Phil Rosenberg <p.d...@gm...>
>> Date:   Fri Feb 27 17:12:03 2015 +0000
>> 
>>     Fixed bug in rdbuf_di.
>>     
>>     Save cursubpage on replot
>>     call plP_eop() on replot which ensures that the first plP_bop() call actually does something.
>> 
>> If I comment out the plP_eop() that was added to plbuf.c in that commit, the xwin driver does not exhibit the problematic behavior.  I will investigate further on working on a patch.  I know why it is causing a problem, but it isn’t obvious to me how it gets to that point.
> 
> I found the cause of the problem and the plP_eop() is not acting in a way that neither Phil nor I expected.  Phil put the plP_eop() in to make sure that the BOP will do something and I thought that will always to lead to the keypress bug.  In reality the plP_eop() does something only half the time.
> 
> 1) Plot starts
> 2) At BOP, the page_status is set to AT_BOP
> 3) While drawing, the page_status is set to DRAWING
> 4) At EOP, the page_status is set to AT_EOP  (the EOP is not put into the buffer)
> 5) The driver enters into a loop waiting for messages
> 6) Driver receives a resize message
> 7) plRemakePlot is called
> 8) plRemakPlot() calls plP_eop()
> 9) plP_eop() does nothing because it exits immediately because the page_status is AT_EOP
> 10) The plot buffer is replayed
> 11) At BOP, the page_status is set to AT_BOP
> 12) While drawing, the page_status is set to DRAWING
> 13) No EOP is generated because it is not in the buffer, thus the page_status is unchanged
> 14) Control returns the message loop
> 15) Another resize message is received
> 16) plRemakePlot is called
> 17) plRemakePlot() calls plP_eop()
> 18) plP_eop() does not exit immediately this time because page_state is DRAWING
> 19) plP_eop() calls the driver EOP handler
> 20) The driver enters into a new loop waiting for messages
> 21) User has to do an action (e.g. keypress) to exit the new message loop.  This blocks many messages because the windowing system still considers the window to be processing a resize.
> 22) Once the new message loop exits, the driver EOP handler exits.
> 23) Goto step 10.
> 
> Just putting the EOP into the plot buffer won’t fix the problem because a new message loop will be called, which will block messages.  
> 
> I agree with Phil’s point about the need to call plP_eop().  Some drivers may need the EOP handler to work correctly (e.g. double buffering). The way the code is structured, the plP_eop() is only doing something 50% of the time. 
> 
> I’m not sure the best way to fix this.  I think the interactive GUI drivers might need to be modified to check if they are already waiting.  One thing that makes this tricky is the strip chart function.  As it is currently written, it does not generate an EOP until the end.  Thus, it cannot be resized while plotting.  Plus, when resized, the entire strip chart is replayed (though I see Phil has made some commits so wxWidgets might be smarter).
> 
> I’m going to experiment on some different approaches and see what works best.
> 

Re: [Plplot-devel] Bug fix to plbuf.c

[Phil R. <p.d...@gm...>]

Hmmm
Then hmmmm some more
Followed by an ummm or two.

As you say Jim, clearly things are more complicated than I realised. I'm not sure what the requirements really are here now. Now you have brought this up I can imagine the issues associated with entering the message loop after an eop.

In terms of dealing with it, I'm not at my computer right now, but I think probably a bop_forced function which forces a bop irrespective of where we are in the page cycle would work. But I'm not sure if that might have some potential subtle effects elsewhere so it is a bit of a hack really. Perhaps instead it would be better to assess what is being done in a bop and ensure those actions end up in the buffer so a bop event is not required.

Phil

-----Original Message-----
From: "Jim Dishaw" <ji...@di...>
Sent: ‎13/‎06/‎2015 17:55
To: "Alan W. Irwin" <ir...@be...>
Cc: "PLplot development list" <Plp...@li...>
Subject: Re: [Plplot-devel] Bug fix to plbuf.c



On Jun 13, 2015, at 12:03 PM, Jim Dishaw <ji...@di...> wrote:




On Jun 11, 2015, at 12:29 AM, Jim Dishaw <ji...@di...> wrote:



On Jun 10, 2015, at 11:30 PM, Alan W. Irwin <ir...@be...> wrote:
 <snip>

Just to confirm that I just now played a lot with resizing of

examples/c/x01c -dev xwin

for 5.10.0, 5.11.0, and git master tip (including your recent commit),
and I found no specific string issues for any of those cases.  So it
appears hard (at least with this example) to demonstrate a rendering
bug due to this issue that you just fixed, but your fix seems logical
to me (now) and certainly does not introduce any bad string rendering
that I can spot.

However, when doing those checks I did notice other resizing issues
that do need to be addressed.

1. As a resize is occurring (typically by dragging one edge or one
corner of the GUI to make the whole thing smaller or larger) sometimes
the displayed GUI is a scaled plot and sometimes it is black (which is
OK).  But on some occasions when I stop resizing (by releasing the
mouse button) the result remains black for 5.11.0 and the master tip
version (which is not OK).  But 5.10.0 is fine in this regard. So this
issue is a regression introduced into PLplot between 5.10.0 and 5.11.0
and probably due to the flurry of changes you and Phil made in plbuf
before we released 5.11.0.




Please verify the good result for 5.10.0 and bad result for 5.11.0,
git bisect to figure out what commit has caused the issue, and then
make the appropriate plbuf fix to get rid of this regression.



I think this problem is the plP_eop() that was inserted in the plRemakePlot() to make sure the BOP would perform as expected.  For the GUI drivers this will trigger another wait for input, which ends up blocking redraw messages.  I will verify by using git bisect.



I ran git bisect and the regression was introduced in the commit 1e402417c1f3e87c391fe428f936153c2a10e8cc


Author: Phil Rosenberg <p.d...@gm...>
Date:   Fri Feb 27 17:12:03 2015 +0000


    Fixed bug in rdbuf_di.
    
    Save cursubpage on replot
    call plP_eop() on replot which ensures that the first plP_bop() call actually does something.


If I comment out the plP_eop() that was added to plbuf.c in that commit, the xwin driver does not exhibit the problematic behavior.  I will investigate further on working on a patch.  I know why it is causing a problem, but it isn’t obvious to me how it gets to that point.




I found the cause of the problem and the plP_eop() is not acting in a way that neither Phil nor I expected.  Phil put the plP_eop() in to make sure that the BOP will do something and I thought that will always to lead to the keypress bug.  In reality the plP_eop() does something only half the time.


1) Plot starts
2) At BOP, the page_status is set to AT_BOP
3) While drawing, the page_status is set to DRAWING
4) At EOP, the page_status is set to AT_EOP  (the EOP is not put into the buffer)
5) The driver enters into a loop waiting for messages
6) Driver receives a resize message
7) plRemakePlot is called
8) plRemakPlot() calls plP_eop()
9) plP_eop() does nothing because it exits immediately because the page_status is AT_EOP
10) The plot buffer is replayed
11) At BOP, the page_status is set to AT_BOP
12) While drawing, the page_status is set to DRAWING
13) No EOP is generated because it is not in the buffer, thus the page_status is unchanged
14) Control returns the message loop
15) Another resize message is received
16) plRemakePlot is called
17) plRemakePlot() calls plP_eop()
18) plP_eop() does not exit immediately this time because page_state is DRAWING
19) plP_eop() calls the driver EOP handler
20) The driver enters into a new loop waiting for messages
21) User has to do an action (e.g. keypress) to exit the new message loop.  This blocks many messages because the windowing system still considers the window to be processing a resize.
22) Once the new message loop exits, the driver EOP handler exits.
23) Goto step 10.


Just putting the EOP into the plot buffer won’t fix the problem because a new message loop will be called, which will block messages.  


I agree with Phil’s point about the need to call plP_eop().  Some drivers may need the EOP handler to work correctly (e.g. double buffering). The way the code is structured, the plP_eop() is only doing something 50% of the time. 


I’m not sure the best way to fix this.  I think the interactive GUI drivers might need to be modified to check if they are already waiting.  One thing that makes this tricky is the strip chart function.  As it is currently written, it does not generate an EOP until the end.  Thus, it cannot be resized while plotting.  Plus, when resized, the entire strip chart is replayed (though I see Phil has made some commits so wxWidgets might be smarter).


I’m going to experiment on some different approaches and see what works best.

Re: [Plplot-devel] Bug fix to plbuf.c

[Jim D. <ji...@di...>]

> On Jun 13, 2015, at 12:03 PM, Jim Dishaw <ji...@di...> wrote:
> 
> 
>> On Jun 11, 2015, at 12:29 AM, Jim Dishaw <ji...@di... <mailto:ji...@di...>> wrote:
>> 
>>> 
>>> On Jun 10, 2015, at 11:30 PM, Alan W. Irwin <ir...@be... <mailto:ir...@be...>> wrote:
>  <snip>
>>> Just to confirm that I just now played a lot with resizing of
>>> 
>>> examples/c/x01c -dev xwin
>>> 
>>> for 5.10.0, 5.11.0, and git master tip (including your recent commit),
>>> and I found no specific string issues for any of those cases.  So it
>>> appears hard (at least with this example) to demonstrate a rendering
>>> bug due to this issue that you just fixed, but your fix seems logical
>>> to me (now) and certainly does not introduce any bad string rendering
>>> that I can spot.
>>> 
>>> However, when doing those checks I did notice other resizing issues
>>> that do need to be addressed.
>>> 
>>> 1. As a resize is occurring (typically by dragging one edge or one
>>> corner of the GUI to make the whole thing smaller or larger) sometimes
>>> the displayed GUI is a scaled plot and sometimes it is black (which is
>>> OK).  But on some occasions when I stop resizing (by releasing the
>>> mouse button) the result remains black for 5.11.0 and the master tip
>>> version (which is not OK).  But 5.10.0 is fine in this regard. So this
>>> issue is a regression introduced into PLplot between 5.10.0 and 5.11.0
>>> and probably due to the flurry of changes you and Phil made in plbuf
>>> before we released 5.11.0.
>> 
>>> 
>>> Please verify the good result for 5.10.0 and bad result for 5.11.0,
>>> git bisect to figure out what commit has caused the issue, and then
>>> make the appropriate plbuf fix to get rid of this regression.
>>> 
>> 
>> I think this problem is the plP_eop() that was inserted in the plRemakePlot() to make sure the BOP would perform as expected.  For the GUI drivers this will trigger another wait for input, which ends up blocking redraw messages.  I will verify by using git bisect.
> 
> I ran git bisect and the regression was introduced in the commit 1e402417c1f3e87c391fe428f936153c2a10e8cc
> 
> Author: Phil Rosenberg <p.d...@gm... <mailto:p.d...@gm...>>
> Date:   Fri Feb 27 17:12:03 2015 +0000
> 
>     Fixed bug in rdbuf_di.
>     
>     Save cursubpage on replot
>     call plP_eop() on replot which ensures that the first plP_bop() call actually does something.
> 
> If I comment out the plP_eop() that was added to plbuf.c in that commit, the xwin driver does not exhibit the problematic behavior.  I will investigate further on working on a patch.  I know why it is causing a problem, but it isn’t obvious to me how it gets to that point.
> 

I found the cause of the problem and the plP_eop() is not acting in a way that neither Phil nor I expected.  Phil put the plP_eop() in to make sure that the BOP will do something and I thought that will always to lead to the keypress bug.  In reality the plP_eop() does something only half the time.

1) Plot starts
2) At BOP, the page_status is set to AT_BOP
3) While drawing, the page_status is set to DRAWING
4) At EOP, the page_status is set to AT_EOP  (the EOP is not put into the buffer)
5) The driver enters into a loop waiting for messages
6) Driver receives a resize message
7) plRemakePlot is called
8) plRemakPlot() calls plP_eop()
9) plP_eop() does nothing because it exits immediately because the page_status is AT_EOP
10) The plot buffer is replayed
11) At BOP, the page_status is set to AT_BOP
12) While drawing, the page_status is set to DRAWING
13) No EOP is generated because it is not in the buffer, thus the page_status is unchanged
14) Control returns the message loop
15) Another resize message is received
16) plRemakePlot is called
17) plRemakePlot() calls plP_eop()
18) plP_eop() does not exit immediately this time because page_state is DRAWING
19) plP_eop() calls the driver EOP handler
20) The driver enters into a new loop waiting for messages
21) User has to do an action (e.g. keypress) to exit the new message loop.  This blocks many messages because the windowing system still considers the window to be processing a resize.
22) Once the new message loop exits, the driver EOP handler exits.
23) Goto step 10.

Just putting the EOP into the plot buffer won’t fix the problem because a new message loop will be called, which will block messages.  

I agree with Phil’s point about the need to call plP_eop().  Some drivers may need the EOP handler to work correctly (e.g. double buffering). The way the code is structured, the plP_eop() is only doing something 50% of the time. 

I’m not sure the best way to fix this.  I think the interactive GUI drivers might need to be modified to check if they are already waiting.  One thing that makes this tricky is the strip chart function.  As it is currently written, it does not generate an EOP until the end.  Thus, it cannot be resized while plotting.  Plus, when resized, the entire strip chart is replayed (though I see Phil has made some commits so wxWidgets might be smarter).

I’m going to experiment on some different approaches and see what works best.

Re: [Plplot-devel] Bug fix to plbuf.c

[Jim D. <ji...@di...>]

> On Jun 11, 2015, at 12:29 AM, Jim Dishaw <ji...@di...> wrote:
> 
>> 
>> On Jun 10, 2015, at 11:30 PM, Alan W. Irwin <ir...@be...> wrote:
 <snip>
>> Just to confirm that I just now played a lot with resizing of
>> 
>> examples/c/x01c -dev xwin
>> 
>> for 5.10.0, 5.11.0, and git master tip (including your recent commit),
>> and I found no specific string issues for any of those cases.  So it
>> appears hard (at least with this example) to demonstrate a rendering
>> bug due to this issue that you just fixed, but your fix seems logical
>> to me (now) and certainly does not introduce any bad string rendering
>> that I can spot.
>> 
>> However, when doing those checks I did notice other resizing issues
>> that do need to be addressed.
>> 
>> 1. As a resize is occurring (typically by dragging one edge or one
>> corner of the GUI to make the whole thing smaller or larger) sometimes
>> the displayed GUI is a scaled plot and sometimes it is black (which is
>> OK).  But on some occasions when I stop resizing (by releasing the
>> mouse button) the result remains black for 5.11.0 and the master tip
>> version (which is not OK).  But 5.10.0 is fine in this regard. So this
>> issue is a regression introduced into PLplot between 5.10.0 and 5.11.0
>> and probably due to the flurry of changes you and Phil made in plbuf
>> before we released 5.11.0.
> 
>> 
>> Please verify the good result for 5.10.0 and bad result for 5.11.0,
>> git bisect to figure out what commit has caused the issue, and then
>> make the appropriate plbuf fix to get rid of this regression.
>> 
> 
> I think this problem is the plP_eop() that was inserted in the plRemakePlot() to make sure the BOP would perform as expected.  For the GUI drivers this will trigger another wait for input, which ends up blocking redraw messages.  I will verify by using git bisect.

I ran git bisect and the regression was introduced in the commit 1e402417c1f3e87c391fe428f936153c2a10e8cc

Author: Phil Rosenberg <p.d...@gm...>
Date:   Fri Feb 27 17:12:03 2015 +0000

    Fixed bug in rdbuf_di.
    
    Save cursubpage on replot
    call plP_eop() on replot which ensures that the first plP_bop() call actually does something.

If I comment out the plP_eop() that was added to plbuf.c in that commit, the xwin driver does not exhibit the problematic behavior.  I will investigate further on working on a patch.  I know why it is causing a problem, but it isn’t obvious to me how it gets to that point.

Re: [Plplot-devel] extcairo w/ GtkAda

[Sundelin H. <hen...@aa...>]

Hi,

Yes, that actually helped, seems to be working now! The initialize function is the default one that comes with the thick Ada binding.

Thanks!

Lähettäjä: James Tappin <jt...@gm...<mailto:jt...@gm...>>
Päivämäärä: Saturday 13 June 2015 00:12
Vastaanottaja: Henri Sundelin <hen...@aa...<mailto:hen...@aa...>>
Kopio: "plp...@li...<mailto:plp...@li...>" <plp...@li...<mailto:plp...@li...>>
Aihe: Re: [Plplot-devel] extcairo w/ GtkAda

>From a quick check of one of the Fortran exmples in gtk-fortran, I think that the problem is that the call is too early. The call to pl_cmd needs to come AFTER the call to plinit or plstar (it seems counter-intuitive but that seems to be the case) -- here is the relevant bit from the gtk version of example one:

    call plscmap0(rval, gval, bval)
    call plsdev("extcairo")

    ! By default the "extcairo" driver does not reset the background
    ! This is equivalent to the command line option "-drvopt set_background=1"
    call plsetopt("drvopt", "set_background=1")

    ! The "extcairo" device doesn't read the size from the context.
    write(geometry, "(I0,'x',I0)") width, height
    call plsetopt("geometry",  geometry)

    !  Divide page into 2x2 plots
    call plstar(2,2)

    ! Tell the "extcairo" driver where the context is located. This must be
    ! done AFTER the plstar or plinit call.

    call pl_cmd(PLESC_DEVINIT, cc)


    !  Do a plot
    call plot1()

Since I don't know exactly what is in your Initialize_PLplot; routine, I can't tell if the pl_cmd needs to come in there or if it can come after.

On 12 June 2015 at 21:24, Sundelin Henri <hen...@aa...<mailto:hen...@aa...>> wrote:
Hi,

I’ve been trying to get the extcairo driver to work with GtkAda. I’ve been trying to replicate the ext-cairo-test.c example, but I haven’t been yet succesful, I get a segfault.. Everything works fine with pdfcairo driver though.

I had to expand the Ada binding a bit, since pl_cmd was not available. Added this to plplot_thin.ads:
   procedure pl_cmd(cmd: PLINT; arg : System.Address);
   pragma Import(C, pl_cmd, "pl_cmd");

The code I’m trying is very simple:
…
       function Convert is new Ada.Unchecked_Conversion (Source => Cairo_Context,
                                                     Target => System.Address);

…
       — init gtkada etc..
…
       Cr := Cairo.Create (surface);

      Set_Device_Name("extcairo");
      pl_cmd( PLESC_DEVINIT,Convert(Cr) );
      Put_line("Cr "&System.Address_Image(Convert(Cr)));
      Initialize_PLplot;
      Simple_Plot(X=>Pt.X, Y1=>Pt.Y,  X_Label=>To_String(Pt.X_Label),
                  Y_Label=>To_String(Pt.Y_Label),Title_Label=>To_String(Pt.Title));
      End_PLplot;
..
Simple_Plot segfaults. The address printed looks valid.

I’m developing on OSX, haven’t yet tried on Linux if it makes any difference.

Thoughts?

//Henri


------------------------------------------------------------------------------

_______________________________________________
Plplot-devel mailing list
Plp...@li...<mailto:Plp...@li...>
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] extcairo w/ GtkAda

[James T. <jt...@gm...>]

>From a quick check of one of the Fortran exmples in gtk-fortran, I think
that the problem is that the call is too early. The call to pl_cmd needs to
come AFTER the call to plinit or plstar (it seems counter-intuitive but
that seems to be the case) -- here is the relevant bit from the gtk version
of example one:

    call plscmap0(rval, gval, bval)
    call plsdev("extcairo")

    ! By default the "extcairo" driver does not reset the background
    ! This is equivalent to the command line option "-drvopt
set_background=1"
    call plsetopt("drvopt", "set_background=1")

    ! The "extcairo" device doesn't read the size from the context.
    write(geometry, "(I0,'x',I0)") width, height
    call plsetopt("geometry",  geometry)

    !  Divide page into 2x2 plots
    call plstar(2,2)

    ! Tell the "extcairo" driver where the context is located. This must be
    ! done AFTER the plstar or plinit call.

    call pl_cmd(PLESC_DEVINIT, cc)


    !  Do a plot
    call plot1()

Since I don't know exactly what is in your Initialize_PLplot; routine, I
can't tell if the pl_cmd needs to come in there or if it can come after.

On 12 June 2015 at 21:24, Sundelin Henri <hen...@aa...> wrote:

>  Hi,
>
>  I’ve been trying to get the extcairo driver to work with GtkAda. I’ve
> been trying to replicate the ext-cairo-test.c example, but I haven’t been
> yet succesful, I get a segfault.. Everything works fine with pdfcairo
> driver though.
>
>  I had to expand the Ada binding a bit, since pl_cmd was not available.
> Added this to plplot_thin.ads:
>     procedure pl_cmd(cmd: PLINT; arg : System.Address);
>    pragma Import(C, pl_cmd, "pl_cmd");
>
>  The code I’m trying is very simple:
> …
>         function Convert is new Ada.Unchecked_Conversion (Source =>
> Cairo_Context,
>                                                      Target =>
> System.Address);
>
>  …
>        — init gtkada etc..
> …
>         Cr := Cairo.Create (surface);
>
>       Set_Device_Name("extcairo");
>       pl_cmd( PLESC_DEVINIT,Convert(Cr) );
>       Put_line("Cr "&System.Address_Image(Convert(Cr)));
>       Initialize_PLplot;
>       Simple_Plot(X=>Pt.X, Y1=>Pt.Y,  X_Label=>To_String(Pt.X_Label),
>
> Y_Label=>To_String(Pt.Y_Label),Title_Label=>To_String(Pt.Title));
>       End_PLplot;
>  ..
> Simple_Plot segfaults. The address printed looks valid.
>
>  I’m developing on OSX, haven’t yet tried on Linux if it makes any
> difference.
>
>  Thoughts?
>
>  //Henri
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>

[Plplot-devel] extcairo w/ GtkAda

[Sundelin H. <hen...@aa...>]

Hi,

I’ve been trying to get the extcairo driver to work with GtkAda. I’ve been trying to replicate the ext-cairo-test.c example, but I haven’t been yet succesful, I get a segfault.. Everything works fine with pdfcairo driver though.

I had to expand the Ada binding a bit, since pl_cmd was not available. Added this to plplot_thin.ads:
   procedure pl_cmd(cmd: PLINT; arg : System.Address);
   pragma Import(C, pl_cmd, "pl_cmd");

The code I’m trying is very simple:
…
       function Convert is new Ada.Unchecked_Conversion (Source => Cairo_Context,
                                                     Target => System.Address);

…
       — init gtkada etc..
…
       Cr := Cairo.Create (surface);

      Set_Device_Name("extcairo");
      pl_cmd( PLESC_DEVINIT,Convert(Cr) );
      Put_line("Cr "&System.Address_Image(Convert(Cr)));
      Initialize_PLplot;
      Simple_Plot(X=>Pt.X, Y1=>Pt.Y,  X_Label=>To_String(Pt.X_Label),
                  Y_Label=>To_String(Pt.Y_Label),Title_Label=>To_String(Pt.Title));
      End_PLplot;
..
Simple_Plot segfaults. The address printed looks valid.

I’m developing on OSX, haven’t yet tried on Linux if it makes any difference.

Thoughts?

//Henri

Re: [Plplot-devel] Driver behavior questions and wingdi preview

[Alan W. I. <ir...@be...>]

On 2015-06-11 12:20-0400 Jim Dishaw wrote:

>
>> On Jun 11, 2015, at 11:42 AM, Alan W. Irwin <ir...@be...> wrote:
>>
>> On 2015-06-10 21:44-0400 Jim Dishaw wrote:
>>
>>> [...]The driver does not support alpha blending or native gradient fills.
>> I’m not sure if it is worthwhile to add these features in this driver,
>> particular with a Direct2D version on the horizon.
>>
>> To Jim and Aaron:
>>
>> I didn't completely understand what Jim said above at first, and that
>> motivated me to look up (via google searches) what Windows subsystems
>> supported the important alpha blending and native (linear) gradient
>> capabilities.  It appears from what I skimmed that both GDI+ and
>> Direct2D support those capabilities which is also consistent with what
>> Jim said above.
>>
>> @Jim: could you please confirm I now have the correct overview?
>
> The GDI API only supports a limited gradient fill capability.  Essentially it can do gradients with a vertical or horizontal orientation.
>
> GDI+ supports horizontal, vertical, and diagonal gradient fills.  It can also do a “path gradient,” which is a closed shape with a gradient that changes from an interior point to the edges.
>
> GDI has the ability to alpha blend a bitmap.  Thus, to implement alpha blending in GDI, the driver would need to draw to a bitmap, apply the alpha blending (possibly sectioning the bitmap if the alpha value is not constant over the bitmap), and blit the bitmap(s) to the window.  Not a difficult change, but how important is it to add?
>
> GDI+ and direct2d has alpha blending brushes and the ability to specify alpha value in colors.
>
>>
>> If that overview is correct, I am hoping we will end up with a driver
>> that supports alpha blending and native gradient via the
>> GDI/GDI+/Direct2D API's (only available for newer Windows platforms)
>> and possibly (if Aaron decides to work on it) also for the
>> GDI/GDI+/Uniscribe API's (available for a wider range of Windows
>> platforms than GDI/GDI+/Direct2D).  In the former case it does make
>> sense to go with Direct2D support of alpha blending and gradient fills
>> if there are some advantages to that API over the corresponding GDI+
>> API.  Of course, if/when the GDI/GDI+/Uniscribe approach is
>> implemented, it will need to use the GDI+ API to support alpha
>> blending and native gradients for the driver, but I am fine with that
>> from the overview perspective.
>
>> From what I can tell, Direct2D is much faster than GDI+ and easier to work with.
>
> It sounds like there will be three drivers
>
> wingdi:  GDI only (and possibly an alpha blending capability) with ASCII and UNICODE (if available) text rendering
> wingdi+: GDI+ (includes alpha blending, maybe native gradients) with UNICODE text rendering
> wind2d: Direct2D (includes alpha blending, native gradients) with UNICODE text rendering
>
> Fortunately, I think the three drivers will be able to share some code.

Hi Jim:

Thanks for your responses above to my questions and comments.

PLplot implements linear gradients at any angle, but from what you
said it appears GDI+ does not have linear gradient capability at
anything other than 0 deg and 90 deg.  Therefore, it sounds like we
will be forced to use the PLplot core software fallback for gradients
for both the wingdi and wingdi+ device drivers. That's an acceptable
limitation (for example, we use that fallback for -dev xwin) although
the core software fallback gradient result typically looks pretty bad
because of aliasing issues.

Also note there is a choice whether to organize wingdi, wingdi+, and
wind2d as separate, single-device, device drivers or as separate
devices for a single device driver.  That latter choice might make it
a little more convenient to share code between those devices.  I
emphasize what approach you take for these three devices is completely
your choice, but I thought I should at least point out that you do
have that choice.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] Jim's 0001-Fixes-to-correct-builds-on-WIN32.patch

[Alan W. I. <ir...@be...>]

On 2015-06-07 00:25-0400 Jim Dishaw wrote:

> I have attached two sets of patches.  One fixes some build problems
I was having with MSVC [...]

Hi Jim:

I have just now (commit id = 6cde620) pushed that first patch series
0001-Fixes-to-correct-builds-on-WIN32.patch after amending it with a
styling change.  That should complete pushing all your recent patch
series that are intended as bug fixes for the current master branch.

@Arjen and Phil:

The conditional compilation changes that are in this commit are not
relevant to Linux (although I tested a build on the platform to make
sure there were no introduced conditional compilation syntax issues). 
These changes are obviously necessary on Jim's Windows platform, but I
suppose it is possible they could adversely affect your own Windows
platforms.  I don't think that is something you need to test
specifically (although you should use git diff to discover the exact
conditional compilation changes that have been made with this commit).
However, some issue with this commit is something you should keep in
mind if your tests in the future run into any build problems for your
various Windows platforms.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Driver behavior questions and wingdi preview

[Jim D. <ji...@di...>]

> On Jun 11, 2015, at 4:06 AM, Phil Rosenberg <p.d...@gm...> wrote:
> 
> Hi Jim
> The documentation states that the provided text height will be in mm.
> The user can set dpi with plspage so you should use the PLStream->xdpi
> and PLStream->ydpi to size your text in pixels. In case the user
> hasn't set this you should use a sensible default. Of course the
> actual value will depend on the monitor, but rather than try to grab
> this it seems that there are two standards and for consistency you
> should use one of these. One is to use 72 pixels per inch so that 1
> pixel = 1 pt. The other is 90 pixels per inch which seems to be the
> default for most svg renderers. For wxWidgets I chose 90 pixels per
> inch. I also noticed tect seems a little smaller than the example
> online (from the cairo driver?) but it does as described in the
> documentation so I am happy with that.

90 dpi is pretty close to the value (96 dpi) that windows reports for most displays.  For high dpi monitors you can get 200 dpi and for printers you get what the device is able to produce (e.g. 600 dpi). There is some hidden magic that windows does to actually put pixels on the screen, so there is some internal conversions between the reported dpi and the actual dpi.  

Evidently, the cell height used by the Hershey fonts is different then the cell height used by Windows fonts (it has something to do with the ascenders and descenders).  That difference in cell height is the reason why for the same value of chrht, the sizes do not match up.  There is a comment in one of the drivers about the need to scale up by to match up the characters with the Hershey fonts.  On my wingdi driver I need to scale by a factor of 1.6 to match the size produced by the SVG driver.

The recommendation in the Windows API is to use GetDeviceCaps () with the LOGPIXELSX/LOGPIXELSY values to get the dpi setting.  Right now I’m ignoring the DPI setting provided by the user.  On native text rendering devices the xdpi/ydpi settings are essentially being used to scale the size of fonts, which (IMHO) abuses the meaning of “DPI”.  

> 
> Then one question is what happens when you resize, do you honour the
> size given initially or do you rescale it with the rest of the plot. I
> chose to honour the initial size, but intend to allow the user to
> select in the future.
> 

Which size are you referring to?  When the window is resized, the driver gets the new dimensions of the client area (via GetClientRect() for displays and GetDeviceCaps() for printers).  It uses the new size to calculate the new scaling between device virtual coordinates (PIXELS_X/PIXELS_Y in PLplot) and the new output device coordinates,  The dpi remains consistent with what Windows reports.

I do need to make some changes to print routine to preserve the same aspect ratio used by the window.  I figure the user would want the print version to match the aspect of the displayed version.

> Phil
> 
> On 11 June 2015 at 07:16, Greg Jung <gv...@gm...> wrote:
>> The recent addition to struct wingcc_dev:
>> PLGraphicsIn gin;
>> Serves no purpose (other than to break backwards compatibility)
>> and shouldn't be propagated.  It was only thrown in there because xwin.c has
>> something similar.
>> 
>>  I would like to try wingdi.c but dont have a baseline file to run a patch
>> against; if you could shoot me the full file (wingdi.c) I could try it.
>> 
>> The cursor coordinate transformations need a ScreenToClient adjustment, I
>> think this works:
>> 
>>   GetClientRect(cursorwnd, &rcClient);
>> 
>>    ScreenToClient(cursorwnd, (LPPOINT)&Message.pt);
>> 
>>    gin->pX = Message.pt.x;
>>    gin->pY = (rcClient.bottom - rcClient.top) - Message.pt.y;
>>    gin->dX = (PLFLT) gin->pX/ (PLFLT) (rcClient.right - rcClient.left - 1);
>>    gin->dY = (PLFLT) gin->pY/ (PLFLT) (rcClient.bottom - rcClient.top - 1);
>> 
>> When the window is created, it really has no business becoming the
>> foreground;
>> We would like to see it, though:
>>    //
>>    ShowWindow( dev->hwnd, SW_SHOWDEFAULT );
>>    BringWindowToTop( dev->hwnd );
>> 
>>  I think, instead of buying into UNICODE/TCHAR ansii, just convert to
>> unicode where needed and call the W functions.  Why keep it complicated.
>> Also, I think the pointer #ifdef/#endif for 64 bits can just use the 64-bits
>> version now for either compilation.
>> 
>> On Wed, Jun 10, 2015 at 6:44 PM, Jim Dishaw <ji...@di...> wrote:
>>> 
>>> I have two questions on driver behavior that I’m trying to figure out.
>>> 
>>> In the new wingdi driver I have implemented text rendering using the GDI
>>> interface.  The current implementation honors the height specified in chrht.
>>> I have measured the heights both on the screen and when printed via wingdi
>>> using the windows print function.  The heights on the output device matches
>>> chrht; however, they appear smaller than the other device outputs (e.g. ps).
>>> Should I scale the fonts up?
>>> 
>>> When printing, the output matches the content on the screen exactly.  If
>>> the background is black on the screen, it is black on the print version.
>>> When I compare to the ps driver, it appears the colored background is
>>> suppressed.  Should I do the same when printing from the wingdi driver?
>>> 
>>> Attached are two patch series for wingdi.  The driver is still in an alpha
>>> state, so I don’t recommend applying to master or any branch that is
>>> important. There is still some issues with the multiple EOP that will
>>> require a keypress after a redraw event (e.g. resize, printing).  Also, I
>>> have forced debugging, so there is a fair amount of output on the console.
>>> Most of the examples appear to render correctly.  The driver does not
>>> support alpha blending or native gradient fills. I’m not sure if it is
>>> worthwhile to add these features in this driver, particular with a Direct2D
>>> version on the horizon.
>>> 
>>> Also this version of the driver is non-unicode to make a lowest common
>>> denominator driver.  I’m going to add unicode support because that appears
>>> to be the standard used by all the maintained/newer drivers.
>>> 
>>> Any feedback is greatly appreciated.
>>> 
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> 
>>> _______________________________________________
>>> Plplot-devel mailing list
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> 
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>> 

Re: [Plplot-devel] Driver behavior questions and wingdi preview

[Jim D. <ji...@di...>]

> On Jun 11, 2015, at 11:42 AM, Alan W. Irwin <ir...@be...> wrote:
> 
> On 2015-06-10 21:44-0400 Jim Dishaw wrote:
> 
>> [...]The driver does not support alpha blending or native gradient fills.
> I’m not sure if it is worthwhile to add these features in this driver,
> particular with a Direct2D version on the horizon.
> 
> To Jim and Aaron:
> 
> I didn't completely understand what Jim said above at first, and that
> motivated me to look up (via google searches) what Windows subsystems
> supported the important alpha blending and native (linear) gradient
> capabilities.  It appears from what I skimmed that both GDI+ and
> Direct2D support those capabilities which is also consistent with what
> Jim said above.
> 
> @Jim: could you please confirm I now have the correct overview?

The GDI API only supports a limited gradient fill capability.  Essentially it can do gradients with a vertical or horizontal orientation.

GDI+ supports horizontal, vertical, and diagonal gradient fills.  It can also do a “path gradient,” which is a closed shape with a gradient that changes from an interior point to the edges.

GDI has the ability to alpha blend a bitmap.  Thus, to implement alpha blending in GDI, the driver would need to draw to a bitmap, apply the alpha blending (possibly sectioning the bitmap if the alpha value is not constant over the bitmap), and blit the bitmap(s) to the window.  Not a difficult change, but how important is it to add?

GDI+ and direct2d has alpha blending brushes and the ability to specify alpha value in colors.
 
> 
> If that overview is correct, I am hoping we will end up with a driver
> that supports alpha blending and native gradient via the
> GDI/GDI+/Direct2D API's (only available for newer Windows platforms)
> and possibly (if Aaron decides to work on it) also for the
> GDI/GDI+/Uniscribe API's (available for a wider range of Windows
> platforms than GDI/GDI+/Direct2D).  In the former case it does make
> sense to go with Direct2D support of alpha blending and gradient fills
> if there are some advantages to that API over the corresponding GDI+
> API.  Of course, if/when the GDI/GDI+/Uniscribe approach is
> implemented, it will need to use the GDI+ API to support alpha
> blending and native gradients for the driver, but I am fine with that
> from the overview perspective.

From what I can tell, Direct2D is much faster than GDI+ and easier to work with.

It sounds like there will be three drivers

wingdi:  GDI only (and possibly an alpha blending capability) with ASCII and UNICODE (if available) text rendering
wingdi+: GDI+ (includes alpha blending, maybe native gradients) with UNICODE text rendering
wind2d: Direct2D (includes alpha blending, native gradients) with UNICODE text rendering

Fortunately, I think the three drivers will be able to share some code.

Re: [Plplot-devel] Driver behavior questions and wingdi preview

[Alan W. I. <ir...@be...>]

On 2015-06-10 21:44-0400 Jim Dishaw wrote:

> [...]The driver does not support alpha blending or native gradient fills.
I’m not sure if it is worthwhile to add these features in this driver,
particular with a Direct2D version on the horizon.

To Jim and Aaron:

I didn't completely understand what Jim said above at first, and that
motivated me to look up (via google searches) what Windows subsystems
supported the important alpha blending and native (linear) gradient
capabilities.  It appears from what I skimmed that both GDI+ and
Direct2D support those capabilities which is also consistent with what
Jim said above.

@Jim: could you please confirm I now have the correct overview?

If that overview is correct, I am hoping we will end up with a driver
that supports alpha blending and native gradient via the
GDI/GDI+/Direct2D API's (only available for newer Windows platforms)
and possibly (if Aaron decides to work on it) also for the
GDI/GDI+/Uniscribe API's (available for a wider range of Windows
platforms than GDI/GDI+/Direct2D).  In the former case it does make
sense to go with Direct2D support of alpha blending and gradient fills
if there are some advantages to that API over the corresponding GDI+
API.  Of course, if/when the GDI/GDI+/Uniscribe approach is
implemented, it will need to use the GDI+ API to support alpha
blending and native gradients for the driver, but I am fine with that
from the overview perspective.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Driver behavior questions and wingdi preview

[Phil R. <p.d...@gm...>]

Hi Jim
The documentation states that the provided text height will be in mm.
The user can set dpi with plspage so you should use the PLStream->xdpi
and PLStream->ydpi to size your text in pixels. In case the user
hasn't set this you should use a sensible default. Of course the
actual value will depend on the monitor, but rather than try to grab
this it seems that there are two standards and for consistency you
should use one of these. One is to use 72 pixels per inch so that 1
pixel = 1 pt. The other is 90 pixels per inch which seems to be the
default for most svg renderers. For wxWidgets I chose 90 pixels per
inch. I also noticed tect seems a little smaller than the example
online (from the cairo driver?) but it does as described in the
documentation so I am happy with that.

Then one question is what happens when you resize, do you honour the
size given initially or do you rescale it with the rest of the plot. I
chose to honour the initial size, but intend to allow the user to
select in the future.

Phil

On 11 June 2015 at 07:16, Greg Jung <gv...@gm...> wrote:
> The recent addition to struct wingcc_dev:
> PLGraphicsIn gin;
> Serves no purpose (other than to break backwards compatibility)
> and shouldn't be propagated.  It was only thrown in there because xwin.c has
> something similar.
>
>   I would like to try wingdi.c but dont have a baseline file to run a patch
> against; if you could shoot me the full file (wingdi.c) I could try it.
>
> The cursor coordinate transformations need a ScreenToClient adjustment, I
> think this works:
>
>    GetClientRect(cursorwnd, &rcClient);
>
>     ScreenToClient(cursorwnd, (LPPOINT)&Message.pt);
>
>     gin->pX = Message.pt.x;
>     gin->pY = (rcClient.bottom - rcClient.top) - Message.pt.y;
>     gin->dX = (PLFLT) gin->pX/ (PLFLT) (rcClient.right - rcClient.left - 1);
>     gin->dY = (PLFLT) gin->pY/ (PLFLT) (rcClient.bottom - rcClient.top - 1);
>
> When the window is created, it really has no business becoming the
> foreground;
> We would like to see it, though:
>     //
>     ShowWindow( dev->hwnd, SW_SHOWDEFAULT );
>     BringWindowToTop( dev->hwnd );
>
>   I think, instead of buying into UNICODE/TCHAR ansii, just convert to
> unicode where needed and call the W functions.  Why keep it complicated.
> Also, I think the pointer #ifdef/#endif for 64 bits can just use the 64-bits
> version now for either compilation.
>
> On Wed, Jun 10, 2015 at 6:44 PM, Jim Dishaw <ji...@di...> wrote:
>>
>> I have two questions on driver behavior that I’m trying to figure out.
>>
>> In the new wingdi driver I have implemented text rendering using the GDI
>> interface.  The current implementation honors the height specified in chrht.
>> I have measured the heights both on the screen and when printed via wingdi
>> using the windows print function.  The heights on the output device matches
>> chrht; however, they appear smaller than the other device outputs (e.g. ps).
>> Should I scale the fonts up?
>>
>> When printing, the output matches the content on the screen exactly.  If
>> the background is black on the screen, it is black on the print version.
>> When I compare to the ps driver, it appears the colored background is
>> suppressed.  Should I do the same when printing from the wingdi driver?
>>
>> Attached are two patch series for wingdi.  The driver is still in an alpha
>> state, so I don’t recommend applying to master or any branch that is
>> important. There is still some issues with the multiple EOP that will
>> require a keypress after a redraw event (e.g. resize, printing).  Also, I
>> have forced debugging, so there is a fair amount of output on the console.
>> Most of the examples appear to render correctly.  The driver does not
>> support alpha blending or native gradient fills. I’m not sure if it is
>> worthwhile to add these features in this driver, particular with a Direct2D
>> version on the horizon.
>>
>>  Also this version of the driver is non-unicode to make a lowest common
>> denominator driver.  I’m going to add unicode support because that appears
>> to be the standard used by all the maintained/newer drivers.
>>
>> Any feedback is greatly appreciated.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] Driver behavior questions and wingdi preview

[Greg J. <gv...@gm...>]

The recent addition to struct wingcc_dev:
PLGraphicsIn gin;
Serves no purpose (other than to break backwards compatibility)
and shouldn't be propagated.  It was only thrown in there because xwin.c has
something similar.

  I would like to try wingdi.c but dont have a baseline file to run a patch
against; if you could shoot me the full file (wingdi.c) I could try it.

The cursor coordinate transformations need a ScreenToClient adjustment, I
think this works:

   GetClientRect(cursorwnd, &rcClient);

    ScreenToClient(cursorwnd, (LPPOINT)&Message.pt);

    gin->pX = Message.pt.x;
    gin->pY = (rcClient.bottom - rcClient.top) - Message.pt.y;
    gin->dX = (PLFLT) gin->pX/ (PLFLT) (rcClient.right - rcClient.left - 1);
    gin->dY = (PLFLT) gin->pY/ (PLFLT) (rcClient.bottom - rcClient.top - 1);

When the window is created, it really has no business becoming the
foreground;
We would like to see it, though:
    //
    ShowWindow( dev->hwnd, SW_SHOWDEFAULT );
    BringWindowToTop( dev->hwnd );

  I think, instead of buying into UNICODE/TCHAR ansii, just convert to
unicode where needed and call the W functions.  Why keep it complicated.
Also, I think the pointer #ifdef/#endif for 64 bits can just use the
64-bits version now for either compilation.

On Wed, Jun 10, 2015 at 6:44 PM, Jim Dishaw <ji...@di...> wrote:

> I have two questions on driver behavior that I’m trying to figure out.
>
> In the new wingdi driver I have implemented text rendering using the GDI
> interface.  The current implementation honors the height specified in
> chrht.  I have measured the heights both on the screen and when printed via
> wingdi using the windows print function.  The heights on the output device
> matches chrht; however, they appear smaller than the other device outputs
> (e.g. ps).  Should I scale the fonts up?
>
> When printing, the output matches the content on the screen exactly.  If
> the background is black on the screen, it is black on the print version.
> When I compare to the ps driver, it appears the colored background is
> suppressed.  Should I do the same when printing from the wingdi driver?
>
> Attached are two patch series for wingdi.  The driver is still in an alpha
> state, so I don’t recommend applying to master or any branch that is
> important. There is still some issues with the multiple EOP that will
> require a keypress after a redraw event (e.g. resize, printing).  Also, I
> have forced debugging, so there is a fair amount of output on the console.
> Most of the examples appear to render correctly.  The driver does not
> support alpha blending or native gradient fills. I’m not sure if it is
> worthwhile to add these features in this driver, particular with a Direct2D
> version on the horizon.
>
>  Also this version of the driver is non-unicode to make a lowest common
> denominator driver.  I’m going to add unicode support because that appears
> to be the standard used by all the maintained/newer drivers.
>
> Any feedback is greatly appreciated.
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>

Re: [Plplot-devel] Bug fix to plbuf.c

[Jim D. <ji...@di...>]

> On Jun 10, 2015, at 11:30 PM, Alan W. Irwin <ir...@be...> wrote:
> 
> On 2015-06-10 19:58-0400 Jim Dishaw wrote:
> 
>>> On Jun 10, 2015, at 3:57 AM, Alan W. Irwin <ir...@be...> wrote:
> 
>>> I am sufficiently concerned by your explanation of this fix above that
>>> I am now beginning to wonder a bit if it was necessary.  Of course, I
>>> could be just missing something, but I would appreciate a fuller
>>> explanation of the fix to make sure of its necessity.
>>> 
>> 
> 
>> The fix is still necessary to replay the plot buffer with a device
> that uses char strings vice the Unicode string. In EscText there are
> two different ways of storing strings.
> 
> Hi Jim:
> 
> Thanks for that additional explanation. To be clear about that, input
> strings in PLplot are a null-terminated series of bytes that
> unicode-unaware devices use directly, and those are always also
> transformed to a known-length array of 32-bit integers that
> unicode-aware devices use.  And I guess I can see why you want to
> store both results in the buffer rather than recreating the
> known-length array from the null-terminated series of bytes for each
> resizing event. Anyhow, if previously you were ignoring the NULL
> termination on the representation using a series of bytes, that is
> indeed a bug, and I am glad you fixed it.
> 
>> Without the patch text strings could show random characters on
> redraw events. With this patch all the strings display correctly on
> resize events.
> 
> I never noticed character problems like that when resizing -dev xwin, but my eye
> may have just missed it.
> 

I never was able to reproduce the problem reliably. It was working fine and then as I added features to the text processing in wingdi, the problem would manifest on some of the examples.  

> Just to confirm that I just now played a lot with resizing of
> 
> examples/c/x01c -dev xwin
> 
> for 5.10.0, 5.11.0, and git master tip (including your recent commit),
> and I found no specific string issues for any of those cases.  So it
> appears hard (at least with this example) to demonstrate a rendering
> bug due to this issue that you just fixed, but your fix seems logical
> to me (now) and certainly does not introduce any bad string rendering
> that I can spot.
> 
> However, when doing those checks I did notice other resizing issues
> that do need to be addressed.
> 
> 1. As a resize is occurring (typically by dragging one edge or one
> corner of the GUI to make the whole thing smaller or larger) sometimes
> the displayed GUI is a scaled plot and sometimes it is black (which is
> OK).  But on some occasions when I stop resizing (by releasing the
> mouse button) the result remains black for 5.11.0 and the master tip
> version (which is not OK).  But 5.10.0 is fine in this regard. So this
> issue is a regression introduced into PLplot between 5.10.0 and 5.11.0
> and probably due to the flurry of changes you and Phil made in plbuf
> before we released 5.11.0.

> 
> Please verify the good result for 5.10.0 and bad result for 5.11.0,
> git bisect to figure out what commit has caused the issue, and then
> make the appropriate plbuf fix to get rid of this regression.
> 

I think this problem is the plP_eop() that was inserted in the plRemakePlot() to make sure the BOP would perform as expected.  For the GUI drivers this will trigger another wait for input, which ends up blocking redraw messages.  I will verify by using git bisect.

> 2. For certain rare patterns of resizing the displayed plot results
> are not scaled properly to fit into the resized GUI so that the plot
> is larger than the resized GUI and clipped at its edges.  Changing the
> resizing slightly immediately fixes the issue completely. The badly
> scaled result is rare so you sometimes have to play around with
> resizing a minute or so until you see it.  This effect is seen in all
> versions of PLplot that I tested. So this issue is a long-standing bug
> in -dev xwin or else the plbuf code rather than a recently introduced
> regression. To help pin this long-standing bug down further, please
> check if it also occurs for either/both wingcc or your new GDI device.
> If so then this is probably a long-standing plbuf bug you will want to
> address with much higher priority (since it likely affects all
> interactive results that are displayed with the help of plbuf) than a
> bug in just -dev xwin.
> 

The problem most likely is in the driver because plbuf is agnostic on the device dimension and scaling. I have a couple of guesses on the cause of this bug.  I will investigate and see if I can patch. 

It will be good to look at xwin because I want to add the ability to open and save plot metafiles for the new version of plrender.  I need to add menus and callback functions to the GUI drivers that plrender can use.  My thought is to have a driver option that would enable that feature.

Re: [Plplot-devel] Bug fix to plbuf.c

[Alan W. I. <ir...@be...>]

On 2015-06-10 19:58-0400 Jim Dishaw wrote:

>> On Jun 10, 2015, at 3:57 AM, Alan W. Irwin <ir...@be...> wrote:

>> I am sufficiently concerned by your explanation of this fix above that
>> I am now beginning to wonder a bit if it was necessary.  Of course, I
>> could be just missing something, but I would appreciate a fuller
>> explanation of the fix to make sure of its necessity.
>>
>

> The fix is still necessary to replay the plot buffer with a device
that uses char strings vice the Unicode string. In EscText there are
two different ways of storing strings.

Hi Jim:

Thanks for that additional explanation. To be clear about that, input
strings in PLplot are a null-terminated series of bytes that
unicode-unaware devices use directly, and those are always also
transformed to a known-length array of 32-bit integers that
unicode-aware devices use.  And I guess I can see why you want to
store both results in the buffer rather than recreating the
known-length array from the null-terminated series of bytes for each
resizing event. Anyhow, if previously you were ignoring the NULL
termination on the representation using a series of bytes, that is
indeed a bug, and I am glad you fixed it.

> Without the patch text strings could show random characters on
redraw events. With this patch all the strings display correctly on
resize events.

I never noticed character problems like that when resizing -dev xwin, but my eye
may have just missed it.

Just to confirm that I just now played a lot with resizing of

examples/c/x01c -dev xwin

for 5.10.0, 5.11.0, and git master tip (including your recent commit),
and I found no specific string issues for any of those cases.  So it
appears hard (at least with this example) to demonstrate a rendering
bug due to this issue that you just fixed, but your fix seems logical
to me (now) and certainly does not introduce any bad string rendering
that I can spot.

However, when doing those checks I did notice other resizing issues
that do need to be addressed.

1. As a resize is occurring (typically by dragging one edge or one
corner of the GUI to make the whole thing smaller or larger) sometimes
the displayed GUI is a scaled plot and sometimes it is black (which is
OK).  But on some occasions when I stop resizing (by releasing the
mouse button) the result remains black for 5.11.0 and the master tip
version (which is not OK).  But 5.10.0 is fine in this regard. So this
issue is a regression introduced into PLplot between 5.10.0 and 5.11.0
and probably due to the flurry of changes you and Phil made in plbuf
before we released 5.11.0.

Please verify the good result for 5.10.0 and bad result for 5.11.0,
git bisect to figure out what commit has caused the issue, and then
make the appropriate plbuf fix to get rid of this regression.

2. For certain rare patterns of resizing the displayed plot results
are not scaled properly to fit into the resized GUI so that the plot
is larger than the resized GUI and clipped at its edges.  Changing the
resizing slightly immediately fixes the issue completely. The badly
scaled result is rare so you sometimes have to play around with
resizing a minute or so until you see it.  This effect is seen in all
versions of PLplot that I tested. So this issue is a long-standing bug
in -dev xwin or else the plbuf code rather than a recently introduced
regression. To help pin this long-standing bug down further, please
check if it also occurs for either/both wingcc or your new GDI device.
If so then this is probably a long-standing plbuf bug you will want to
address with much higher priority (since it likely affects all
interactive results that are displayed with the help of plbuf) than a
bug in just -dev xwin.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] Driver behavior questions and wingdi preview

[Jim D. <ji...@di...>]

I have two questions on driver behavior that I’m trying to figure out.  

In the new wingdi driver I have implemented text rendering using the GDI interface.  The current implementation honors the height specified in chrht.  I have measured the heights both on the screen and when printed via wingdi using the windows print function.  The heights on the output device matches chrht; however, they appear smaller than the other device outputs (e.g. ps).  Should I scale the fonts up?

When printing, the output matches the content on the screen exactly.  If the background is black on the screen, it is black on the print version.  When I compare to the ps driver, it appears the colored background is suppressed.  Should I do the same when printing from the wingdi driver?

Attached are two patch series for wingdi.  The driver is still in an alpha state, so I don’t recommend applying to master or any branch that is important. There is still some issues with the multiple EOP that will require a keypress after a redraw event (e.g. resize, printing).  Also, I have forced debugging, so there is a fair amount of output on the console. Most of the examples appear to render correctly.  The driver does not support alpha blending or native gradient fills. I’m not sure if it is worthwhile to add these features in this driver, particular with a Direct2D version on the horizon. 

 Also this version of the driver is non-unicode to make a lowest common denominator driver.  I’m going to add unicode support because that appears to be the standard used by all the maintained/newer drivers.

Any feedback is greatly appreciated.

Re: [Plplot-devel] Bug fix to plbuf.c

[Jim D. <ji...@di...>]

> On Jun 10, 2015, at 3:57 AM, Alan W. Irwin <ir...@be...> wrote:
> 
>> On 2015-06-09 23:10-0400 Jim Dishaw wrote:
>> 
>> 
>>> On Jun 9, 2015, at 10:39 PM, Alan W. Irwin <ir...@be...> wrote:
>>> 
>>> On 2015-06-09 18:18-0400 Jim Dishaw wrote:
>>> 
>>>> Attached is a patch series that corrects a NUL termination bug in
>>> the plot buffer that I discovered while working on the windows GDI
>>> driver.
>>> 
>>> Hi Jim:
>>> 
>>> I applied this result to a private branch using "git am", styled this
>>> result (which was very easy to do, see previous comment), amended your
>>> commit with those style changes using "git add" and "git commit
>>> --amend", and then pushed that result using the normal procedure in
>>> README.developers as commit id = 868f790.
>> Thanks, I will get uncrustify working on the Windows machine I’m using so I don’t keep inconveniencing you.
>> 
>>> Note, I did not test this commit in the slightest, but I assumed you
>>> had done that already.
> 
>> The benefit of developing the the windows GDI driver is that it is
> exercising code pathways in the plot buffer that have never been
> tested.  It appears that all the other GUI drivers have shifted to
> using unicode for strings.  This error affects drivers that use
> regular strings and rely on the plot buffer, which is a very small
> set.
> 
> Hi Jim:
> 
> I am sufficiently concerned by your explanation of this fix above that
> I am now beginning to wonder a bit if it was necessary.  Of course, I
> could be just missing something, but I would appreciate a fuller
> explanation of the fix to make sure of its necessity.
> 

The fix is still necessary to replay the plot buffer with a device that uses char strings vice the Unicode string. In EscText there are two different ways of storing strings. 

> Here is some random stuff I know about our method of dealing with
> unicode which might help to clarify the discussion.
> 
> Input strings for PLplot are all in the UTF-8 representation of
> unicode whether representing glyphs that require a multi-byte UTF-8
> representation or glyphs that require only a single-byte (ascii) but
> still UTF-8 representation of glyphs. In all cases these input strings
> are a series of bytes which are null-terminated. So I really don't see
> how you are getting null-termination problems for some devices and not
> others.  Also, the xwin device driver (which is available on Cygwin,
> Mac OS X, and Linux) is an example of a driver that uses regular
> strings and relies on the plot buffer.  So this driver should be an
> excellent test case for us of plbuf changes that you do for the
> regular strings case.
> 
> How should the latest change of yours affect the xwin device driver
> results?
> 

Without the patch text strings could show random characters on redraw events. With this patch all the strings display correctly on resize events. 

> Alan
> __________________________
> Alan W. Irwin
> 
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> 
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
> 
> Linux-powered Science
> __________________________

Re: [Plplot-devel] Bug fix to plbuf.c

[Alan W. I. <ir...@be...>]

On 2015-06-09 23:10-0400 Jim Dishaw wrote:

>
>> On Jun 9, 2015, at 10:39 PM, Alan W. Irwin <ir...@be...> wrote:
>>
>> On 2015-06-09 18:18-0400 Jim Dishaw wrote:
>>
>>> Attached is a patch series that corrects a NUL termination bug in
>> the plot buffer that I discovered while working on the windows GDI
>> driver.
>>
>> Hi Jim:
>>
>> I applied this result to a private branch using "git am", styled this
>> result (which was very easy to do, see previous comment), amended your
>> commit with those style changes using "git add" and "git commit
>> --amend", and then pushed that result using the normal procedure in
>> README.developers as commit id = 868f790.
>>
> Thanks, I will get uncrustify working on the Windows machine I’m using so I don’t keep inconveniencing you.
>
>> Note, I did not test this commit in the slightest, but I assumed you
>> had done that already.
>

> The benefit of developing the the windows GDI driver is that it is
exercising code pathways in the plot buffer that have never been
tested.  It appears that all the other GUI drivers have shifted to
using unicode for strings.  This error affects drivers that use
regular strings and rely on the plot buffer, which is a very small
set.

Hi Jim:

I am sufficiently concerned by your explanation of this fix above that
I am now beginning to wonder a bit if it was necessary.  Of course, I
could be just missing something, but I would appreciate a fuller
explanation of the fix to make sure of its necessity.

Here is some random stuff I know about our method of dealing with
unicode which might help to clarify the discussion.

Input strings for PLplot are all in the UTF-8 representation of
unicode whether representing glyphs that require a multi-byte UTF-8
representation or glyphs that require only a single-byte (ascii) but
still UTF-8 representation of glyphs. In all cases these input strings
are a series of bytes which are null-terminated. So I really don't see
how you are getting null-termination problems for some devices and not
others.  Also, the xwin device driver (which is available on Cygwin,
Mac OS X, and Linux) is an example of a driver that uses regular
strings and relies on the plot buffer.  So this driver should be an
excellent test case for us of plbuf changes that you do for the
regular strings case.

How should the latest change of yours affect the xwin device driver
results?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Bug fix to plbuf.c

[Jim D. <ji...@di...>]

> On Jun 9, 2015, at 10:39 PM, Alan W. Irwin <ir...@be...> wrote:
> 
> On 2015-06-09 18:18-0400 Jim Dishaw wrote:
> 
>> Attached is a patch series that corrects a NUL termination bug in
> the plot buffer that I discovered while working on the windows GDI
> driver.
> 
> Hi Jim:
> 
> I applied this result to a private branch using "git am", styled this
> result (which was very easy to do, see previous comment), amended your
> commit with those style changes using "git add" and "git commit
> --amend", and then pushed that result using the normal procedure in
> README.developers as commit id = 868f790.
> 
Thanks, I will get uncrustify working on the Windows machine I’m using so I don’t keep inconveniencing you.

> Note, I did not test this commit in the slightest, but I assumed you
> had done that already.

The benefit of developing the the windows GDI driver is that it is exercising code pathways in the plot buffer that have never been tested.  It appears that all the other GUI drivers have shifted to using unicode for strings.  This error affects drivers that use regular strings and rely on the plot buffer, which is a very small set.  I’m still working on the solution to the multiple keypress bug.