plplot-devel

[Plplot-devel] The multiple keypress problem when using interactive drivers

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

While working on my old Windows GDI based driver (see attached patches), I stumbled across the problem that prompted Phil to add plP_eop() in plRemakePlot(). This is related to the issue that Andrew raised on 3/29 on problems with -np when running automated testing.

In plbuf.c, the EOP is never inserted into the plot buffer while the plot is being generated.  The obvious issue to having an EOP in the plot buffer is that it would trigger the device EOP handler (e.g. plD_eop_xw) and in a GUI driver that could cause problems (i.e. the WaitForPage() in the xwin driver would be called multiple times). While working on wxwidgets, Phil added a call to plP_eop() in the plRemakePlot() function in plbuf.c, which triggers the EOP handler and results in the need for a keypress.  I thought eliminating the call to plP_eop() would be the simple fix (it does fix the bug) but having the EOP is handy when redrawing the plot.

I looked at the possibility of keeping the EOP in the plot buffer, but there is all sorts of messy code on trying to “do the right thing” that I think might cause more problems.  In the ideal world, I like the symmetry of having both a BOP and EOP in the plot buffer.  However, to support that correctly in the GUI drivers might be tricky.  Instead, I think the best solution is to eliminate the plP_eop() call that was added into plRemakePlot. That will fix the issue that Andrew raised.  The downside is that Phil might need to make some changes to wxwidgets.  It took some effort to get the new windows GDI driver working without the plP_eop() call, but it does work.  I can make a fix for plbuf.c that removes the plP_eop().

@Aaron & Alan (and others who might be interested)
I have attached two sets of patches.  One fixes some build problems I was having with MSVC and the second implements the new windows GDI driver (which is mostly done).  I need to add some features that I had in my old driver (coordinate point picking, optional tab interface, saving plots into files, optional menu bar).  Should I add Freetype back in?

Once I finish with wingdi, I will implement the Direct2D version.


@Alan

I was not able to uncrustify.  I have not had time to set it up on my Windows machine.  Sorry.

Re: [Plplot-devel] The multiple keypress problem when using interactive drivers

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

The eop call is required because there is some code in bop that needs
to be called, but if bop is called before eop then that function just
returns.

I am sure that you will find the same thing for the Windows driver too.

To be honest I was recently thinking that the buffer is fast
approaching a rather uncomfortable midway point between either
representing only graphics operation or representing pllot commands.
This comes from the fact that drivers also sit in this uncomfortable
midway point. A good example is the clear operation. The clear
operation should clear the subpage, but that requires the driver to
know the subpage geometry so instead of the driver receiving the
graphics operation of "fill this rectangle with the background colour)
it is left for the drivers to fish that geometry from the stream. I
can understand why this is done because some drivers may be able to
actually clear regions rather than just draw a box.

For now I think we just have to live with it and work the buffer as
best we can, in this uncomfortable zone. But in the long term I would
suggest that the drivers should not be given access to the stream.
This will put them solidly in the graphics device region and make the
buffer way simpler.

But at the same time we have plenty of other stuff to do so I don't
think this is anything like a priority at the moment.

Phil

On 7 June 2015 at 05:25, Jim Dishaw <ji...@di...> wrote:
> While working on my old Windows GDI based driver (see attached patches), I stumbled across the problem that prompted Phil to add plP_eop() in plRemakePlot(). This is related to the issue that Andrew raised on 3/29 on problems with -np when running automated testing.
>
> In plbuf.c, the EOP is never inserted into the plot buffer while the plot is being generated.  The obvious issue to having an EOP in the plot buffer is that it would trigger the device EOP handler (e.g. plD_eop_xw) and in a GUI driver that could cause problems (i.e. the WaitForPage() in the xwin driver would be called multiple times). While working on wxwidgets, Phil added a call to plP_eop() in the plRemakePlot() function in plbuf.c, which triggers the EOP handler and results in the need for a keypress.  I thought eliminating the call to plP_eop() would be the simple fix (it does fix the bug) but having the EOP is handy when redrawing the plot.
>
> I looked at the possibility of keeping the EOP in the plot buffer, but there is all sorts of messy code on trying to “do the right thing” that I think might cause more problems.  In the ideal world, I like the symmetry of having both a BOP and EOP in the plot buffer.  However, to support that correctly in the GUI drivers might be tricky.  Instead, I think the best solution is to eliminate the plP_eop() call that was added into plRemakePlot. That will fix the issue that Andrew raised.  The downside is that Phil might need to make some changes to wxwidgets.  It took some effort to get the new windows GDI driver working without the plP_eop() call, but it does work.  I can make a fix for plbuf.c that removes the plP_eop().
>
> @Aaron & Alan (and others who might be interested)
> I have attached two sets of patches.  One fixes some build problems I was having with MSVC and the second implements the new windows GDI driver (which is mostly done).  I need to add some features that I had in my old driver (coordinate point picking, optional tab interface, saving plots into files, optional menu bar).  Should I add Freetype back in?
>
> Once I finish with wingdi, I will implement the Direct2D version.
>
>
> @Alan
>
> I was not able to uncrustify.  I have not had time to set it up on my Windows machine.  Sorry.
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] The multiple keypress problem when using interactive drivers

[Aaron H. <he...@co...>]

Jim,

Thanks for providing these patches.  I'll try to steal some time to try them out.  I'm not sure I understand the reason you're asking about adding Freetype back.  Is it not possible to eliminate it and still get nice looking anti-aliased text with GDI/GDI+/Uniscribe?

Thanks,

Aaron.

-----Original Message-----
From: Jim Dishaw [mailto:ji...@di...] 
Sent: Saturday, June 06, 2015 11:26 PM
To: PLplot development list
Cc: Aaron Hexamer
Subject: The multiple keypress problem when using interactive drivers

While working on my old Windows GDI based driver (see attached patches), I stumbled across the problem that prompted Phil to add plP_eop() in plRemakePlot(). This is related to the issue that Andrew raised on 3/29 on problems with -np when running automated testing.

In plbuf.c, the EOP is never inserted into the plot buffer while the plot is being generated.  The obvious issue to having an EOP in the plot buffer is that it would trigger the device EOP handler (e.g. plD_eop_xw) and in a GUI driver that could cause problems (i.e. the WaitForPage() in the xwin driver would be called multiple times). While working on wxwidgets, Phil added a call to plP_eop() in the plRemakePlot() function in plbuf.c, which triggers the EOP handler and results in the need for a keypress.  I thought eliminating the call to plP_eop() would be the simple fix (it does fix the bug) but having the EOP is handy when redrawing the plot.

I looked at the possibility of keeping the EOP in the plot buffer, but there is all sorts of messy code on trying to  do the right thing  that I think might cause more problems.  In the ideal world, I like the symmetry of having both a BOP and EOP in the plot buffer.  However, to support that correctly in the GUI drivers might be tricky.  Instead, I think the best solution is to eliminate the plP_eop() call that was added into plRemakePlot. That will fix the issue that Andrew raised.  The downside is that Phil might need to make some changes to wxwidgets.  It took some effort to get the new windows GDI driver working without the plP_eop() call, but it does work.  I can make a fix for plbuf.c that removes the plP_eop().

@Aaron & Alan (and others who might be interested) I have attached two sets of patches.  One fixes some build problems I was having with MSVC and the second implements the new windows GDI driver (which is mostly done).  I need to add some features that I had in my old driver (coordinate point picking, optional tab interface, saving plots into files, optional menu bar).  Should I add Freetype back in?

Once I finish with wingdi, I will implement the Direct2D version.


@Alan

I was not able to uncrustify.  I have not had time to set it up on my Windows machine.  Sorry.

Re: [Plplot-devel] The multiple keypress problem when using interactive drivers

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

No real reason for adding Freetype back in. I thought some people might like it. I can keep it a pure windows API driver--easier for me. 



> On Jun 7, 2015, at 10:40 AM, Aaron Hexamer <he...@co...> wrote:
> 
> Jim,
> 
> Thanks for providing these patches.  I'll try to steal some time to try them out.  I'm not sure I understand the reason you're asking about adding Freetype back.  Is it not possible to eliminate it and still get nice looking anti-aliased text with GDI/GDI+/Uniscribe?
> 
> Thanks,
> 
> Aaron.
> 
> -----Original Message-----
> From: Jim Dishaw [mailto:ji...@di...] 
> Sent: Saturday, June 06, 2015 11:26 PM
> To: PLplot development list
> Cc: Aaron Hexamer
> Subject: The multiple keypress problem when using interactive drivers
> 
> While working on my old Windows GDI based driver (see attached patches), I stumbled across the problem that prompted Phil to add plP_eop() in plRemakePlot(). This is related to the issue that Andrew raised on 3/29 on problems with -np when running automated testing.
> 
> In plbuf.c, the EOP is never inserted into the plot buffer while the plot is being generated.  The obvious issue to having an EOP in the plot buffer is that it would trigger the device EOP handler (e.g. plD_eop_xw) and in a GUI driver that could cause problems (i.e. the WaitForPage() in the xwin driver would be called multiple times). While working on wxwidgets, Phil added a call to plP_eop() in the plRemakePlot() function in plbuf.c, which triggers the EOP handler and results in the need for a keypress.  I thought eliminating the call to plP_eop() would be the simple fix (it does fix the bug) but having the EOP is handy when redrawing the plot.
> 
> I looked at the possibility of keeping the EOP in the plot buffer, but there is all sorts of messy code on trying to  do the right thing  that I think might cause more problems.  In the ideal world, I like the symmetry of having both a BOP and EOP in the plot buffer.  However, to support that correctly in the GUI drivers might be tricky.  Instead, I think the best solution is to eliminate the plP_eop() call that was added into plRemakePlot. That will fix the issue that Andrew raised.  The downside is that Phil might need to make some changes to wxwidgets.  It took some effort to get the new windows GDI driver working without the plP_eop() call, but it does work.  I can make a fix for plbuf.c that removes the plP_eop().
> 
> @Aaron & Alan (and others who might be interested) I have attached two sets of patches.  One fixes some build problems I was having with MSVC and the second implements the new windows GDI driver (which is mostly done).  I need to add some features that I had in my old driver (coordinate point picking, optional tab interface, saving plots into files, optional menu bar).  Should I add Freetype back in?
> 
> Once I finish with wingdi, I will implement the Direct2D version.
> 
> 
> @Alan
> 
> I was not able to uncrustify.  I have not had time to set it up on my Windows machine.  Sorry.
> 
> 
> 

Re: [Plplot-devel] The multiple keypress problem when using interactive drivers

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

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

> While working on my old Windows GDI based driver (see attached patches), I stumbled across the problem that prompted Phil to add plP_eop() in plRemakePlot(). This is related to the issue that Andrew raised on 3/29 on problems with -np when running automated testing.
>
> In plbuf.c, the EOP is never inserted into the plot buffer while the plot is being generated.  The obvious issue to having an EOP in the plot buffer is that it would trigger the device EOP handler (e.g. plD_eop_xw) and in a GUI driver that could cause problems (i.e. the WaitForPage() in the xwin driver would be called multiple times). While working on wxwidgets, Phil added a call to plP_eop() in the plRemakePlot() function in plbuf.c, which triggers the EOP handler and results in the need for a keypress.  I thought eliminating the call to plP_eop() would be the simple fix (it does fix the bug) but having the EOP is handy when redrawing the plot.
>
> I looked at the possibility of keeping the EOP in the plot buffer, but there is all sorts of messy code on trying to “do the right thing” that I think might cause more problems.  In the ideal world, I like the symmetry of having both a BOP and EOP in the plot buffer.  However, to support that correctly in the GUI drivers might be tricky.  Instead, I think the best solution is to eliminate the plP_eop() call that was added into plRemakePlot. That will fix the issue that Andrew raised.  The downside is that Phil might need to make some changes to wxwidgets.  It took some effort to get the new windows GDI driver working without the plP_eop() call, but it does work.  I can make a fix for plbuf.c that removes the plP_eop().
>

> @Aaron & Alan (and others who might be interested) I have attached
two sets of patches.  One fixes some build problems I was having with
MSVC and the second implements the new windows GDI driver (which is
mostly done).  I need to add some features that I had in my old driver
(coordinate point picking, optional tab interface, saving plots into
files, optional menu bar).

@Arjen and Phil:

Will you two please take a close look at Jim's patch series concerning
MSVC build problems?  If you try them out and they definitely improve
the build on MSVC, then I think we should push them now as a bug fix
so they will be part of the forthcoming release.

> Should I add Freetype back in?
> Once I finish with wingdi, I will implement the Direct2D version.

Aaron responded to this by asking

"Is it not possible to eliminate it [the plfreetype approach] and still get nice looking
anti-aliased text with GDI/GDI+/Uniscribe?"

@Aaron and Jim:

Here is my response to both of you on these interesting questions.

@Jim:

The quick answer is no, don't bother with the currently deprecated
plfreetype approach and instead move forward with your plans to
implement a Direct2D approach for your successor to the wingcc
device driver.

@Aaron: I encourage you to add to Jim's planned Direct2D approach by 
implementing a Uniscribe approach as well for the case where the user
has an older Windows system with no Direct2D available.

@Jim and Aaron: I hope that division of the labour works for you.

You should also note that in earlier parts of this discussion Phil
mentioned the possibility of modifying the currently deprecated
plfreetype approach to take care of its known issues with finding
glyphs in system fonts and rendering those glyphs properly for complex
text layout languages.  Specifically, he proposed we should deal with
those issues by using the capabilities of the GTK+ components,
fontconfig, pango, and harfbuzz which are available on both Unix and
Windows platforms.  I think that would be a very useful project if
someone wants to take that on.  However, such an approach would have
some obvious dependencies on GTK+ components that are going to
irritate some Windows users.  So if/when the plfreetype approach is
modified as above would be the time to add it back into the successor
to wingcc as an alternative to the Uniscribe and Direct2D alternatives
that should also be available.

> @Alan
>
> I was not able to uncrustify.  I have not had time to set it up on my Windows machine.  Sorry.

@Jim:

No problem.

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] The multiple keypress problem when using interactive drivers

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

> On Jun 7, 2015, at 9:53 AM, Phil Rosenberg <p.d...@gm...> wrote:
> 
> The eop call is required because there is some code in bop that needs
> to be called, but if bop is called before eop then that function just
> returns.
> 
> I am sure that you will find the same thing for the Windows driver too.
> 

The extra plP_eop() causes problems on the new wingdi driver that I wrote.  Nothing insurmountable, but I will dig around for a solution that also fixes the multiple keypress bug.

> To be honest I was recently thinking that the buffer is fast
> approaching a rather uncomfortable midway point between either
> representing only graphics operation or representing pllot commands.
> This comes from the fact that drivers also sit in this uncomfortable
> midway point. A good example is the clear operation. The clear
> operation should clear the subpage, but that requires the driver to
> know the subpage geometry so instead of the driver receiving the
> graphics operation of "fill this rectangle with the background colour)
> it is left for the drivers to fish that geometry from the stream. I
> can understand why this is done because some drivers may be able to
> actually clear regions rather than just draw a box.
> 
> For now I think we just have to live with it and work the buffer as
> best we can, in this uncomfortable zone. But in the long term I would
> suggest that the drivers should not be given access to the stream.
> This will put them solidly in the graphics device region and make the
> buffer way simpler.
> 

I agree.  In the new wingdi I tried to minimize the use of the stream.

> But at the same time we have plenty of other stuff to do so I don't
> think this is anything like a priority at the moment.
> 
> Phil
> 
> On 7 June 2015 at 05:25, Jim Dishaw <ji...@di...> wrote:
>> While working on my old Windows GDI based driver (see attached patches), I stumbled across the problem that prompted Phil to add plP_eop() in plRemakePlot(). This is related to the issue that Andrew raised on 3/29 on problems with -np when running automated testing.
>> 
>> In plbuf.c, the EOP is never inserted into the plot buffer while the plot is being generated.  The obvious issue to having an EOP in the plot buffer is that it would trigger the device EOP handler (e.g. plD_eop_xw) and in a GUI driver that could cause problems (i.e. the WaitForPage() in the xwin driver would be called multiple times). While working on wxwidgets, Phil added a call to plP_eop() in the plRemakePlot() function in plbuf.c, which triggers the EOP handler and results in the need for a keypress.  I thought eliminating the call to plP_eop() would be the simple fix (it does fix the bug) but having the EOP is handy when redrawing the plot.
>> 
>> I looked at the possibility of keeping the EOP in the plot buffer, but there is all sorts of messy code on trying to “do the right thing” that I think might cause more problems.  In the ideal world, I like the symmetry of having both a BOP and EOP in the plot buffer.  However, to support that correctly in the GUI drivers might be tricky.  Instead, I think the best solution is to eliminate the plP_eop() call that was added into plRemakePlot. That will fix the issue that Andrew raised.  The downside is that Phil might need to make some changes to wxwidgets.  It took some effort to get the new windows GDI driver working without the plP_eop() call, but it does work.  I can make a fix for plbuf.c that removes the plP_eop().
>> 
>> @Aaron & Alan (and others who might be interested)
>> I have attached two sets of patches.  One fixes some build problems I was having with MSVC and the second implements the new windows GDI driver (which is mostly done).  I need to add some features that I had in my old driver (coordinate point picking, optional tab interface, saving plots into files, optional menu bar).  Should I add Freetype back in?
>> 
>> Once I finish with wingdi, I will implement the Direct2D version.
>> 
>> 
>> @Alan
>> 
>> I was not able to uncrustify.  I have not had time to set it up on my Windows machine.  Sorry.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> 
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>> 

Re: [Plplot-devel] The multiple keypress problem when using interactive drivers

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

>
> I agree.  In the new wingdi I tried to minimize the use of the stream.
>
Out of curiosity, how do you deal with redraws then - or do you just
not scale anything and store the bitmap for refreshing?

Phil

Re: [Plplot-devel] The multiple keypress problem when using interactive drivers

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

On Jun 8, 2015, at 7:24 AM, Phil Rosenberg <p.d...@gm...> wrote:

>> 
>> I agree.  In the new wingdi I tried to minimize the use of the stream.
> Out of curiosity, how do you deal with redraws then - or do you just
> not scale anything and store the bitmap for refreshing?
> 

I looked at using the stretched blit, but I didn't think it would give good results of the plot was small and the maximized. I'm still using the plRemakePlot, which is why I'm having problems with the extra plP_eop call. 

Re: [Plplot-devel] The multiple keypress problem when usinginteractive drivers

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

Unfortunately you are correct, you get poor results and even when drawing you need to store your coordinates with subpixel resolution by telling plplot that your window is bigger than it really is. My understanding is that wxWidgets is mostly similar to the windows API so you might find checking what is done there helps. Any questions just ask.

Good luck
Phil

-----Original Message-----
From: "Jim Dishaw" <ji...@di...>
Sent: ‎08/‎06/‎2015 12:54
To: "Phil Rosenberg" <p.d...@gm...>
Cc: "PLplot development list" <Plp...@li...>
Subject: Re: [Plplot-devel] The multiple keypress problem when usinginteractive drivers


On Jun 8, 2015, at 7:24 AM, Phil Rosenberg <p.d...@gm...> wrote:

>> 
>> I agree.  In the new wingdi I tried to minimize the use of the stream.
> Out of curiosity, how do you deal with redraws then - or do you just
> not scale anything and store the bitmap for refreshing?
> 

I looked at using the stretched blit, but I didn't think it would give good results of the plot was small and the maximized. I'm still using the plRemakePlot, which is why I'm having problems with the extra plP_eop call. 

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