Pull 7 patches: no clipping, warning fixes

[Max Kellermann]

John: please note that "const" doesn't have any effect on integral
return types, and makes gcc emit a warning.  Did you mean to make the
method itself const?  That would have been a different syntax.


Max Kellermann (7):
      Screen/Chart: use unclipped drawing functions
      FlightStatistics: use unclipped circle drawing method
      Screen/Canvas: removed clipped circle drawing method
      Screen/Canvas: removed clipped polygon drawing methods
      test: added program RunPaintCanvas
      TaskImpl: added missing stdio.h include
      Task, Logger: no integral "const" return types

 Common/Header/Logger.h             |    6 -
 Common/Header/LoggerImpl.hpp       |    6 -
 Common/Header/Screen/Canvas.hpp    |   45 ---------
 Common/Header/Screen/Util.hpp      |    7 -
 Common/Header/Task.h               |   48 ++++-----
 Common/Header/TaskImpl.hpp         |   50 +++++-----
 Common/Source/FlightStatistics.cpp |    3
 Common/Source/Logger.cpp           |    6 -
 Common/Source/LoggerImpl.cpp       |    6 -
 Common/Source/LoggerSign.cpp       |    2
 Common/Source/Screen/Canvas.cpp    |   77 ---------------
 Common/Source/Screen/Chart.cpp     |   35 ++-----
 Common/Source/Screen/Util.cpp      |   12 +-
 Common/Source/Task.cpp             |   34 +++---
 Common/Source/TaskImpl.cpp         |   38 +++----
 test/Makefile                      |   25 ++++-
 test/src/RunPaintCanvas.cpp        |  182 +++++++++++++++++++++++++++++++++++++
 17 files changed, 317 insertions(+), 265 deletions(-)


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Xcsoar-devel mailing list
Xcsoar-devel@...
https://lists.sourceforge.net/lists/listinfo/xcsoar-devel

[John Wharington-2]

Hi Max,

Unfortunately GDI does NOT do all the clipping work.  Several PDA/PNAs
do not clip correctly, and in any case the polygon fill rendering (e.g.
for airspace) when the bounds are outside was known to fail before we
implemented our own clipping system.  It has to be restored.

const double fred() {} is no good?  ok.

On Tue, 2009-09-22 at 12:41 +0200, Max Kellermann wrote:

> John: please note that "const" doesn't have any effect on integral
> return types, and makes gcc emit a warning.  Did you mean to make the
> method itself const?  That would have been a different syntax.
>
>
> Max Kellermann (7):
>       Screen/Chart: use unclipped drawing functions
>       FlightStatistics: use unclipped circle drawing method
>       Screen/Canvas: removed clipped circle drawing method
>       Screen/Canvas: removed clipped polygon drawing methods
>       test: added program RunPaintCanvas
>       TaskImpl: added missing stdio.h include
>       Task, Logger: no integral "const" return types
>
>  Common/Header/Logger.h             |    6 -
>  Common/Header/LoggerImpl.hpp       |    6 -
>  Common/Header/Screen/Canvas.hpp    |   45 ---------
>  Common/Header/Screen/Util.hpp      |    7 -
>  Common/Header/Task.h               |   48 ++++-----
>  Common/Header/TaskImpl.hpp         |   50 +++++-----
>  Common/Source/FlightStatistics.cpp |    3
>  Common/Source/Logger.cpp           |    6 -
>  Common/Source/LoggerImpl.cpp       |    6 -
>  Common/Source/LoggerSign.cpp       |    2
>  Common/Source/Screen/Canvas.cpp    |   77 ---------------
>  Common/Source/Screen/Chart.cpp     |   35 ++-----
>  Common/Source/Screen/Util.cpp      |   12 +-
>  Common/Source/Task.cpp             |   34 +++---
>  Common/Source/TaskImpl.cpp         |   38 +++----
>  test/Makefile                      |   25 ++++-
>  test/src/RunPaintCanvas.cpp        |  182 +++++++++++++++++++++++++++++++++++++
>  17 files changed, 317 insertions(+), 265 deletions(-)
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Xcsoar-devel mailing list
Xcsoar-devel@...
https://lists.sourceforge.net/lists/listinfo/xcsoar-devel

[Max Kellermann]

On 2009/09/22 15:43, John Wharington <jwharington@...> wrote:
> Unfortunately GDI does NOT do all the clipping work.  Several PDA/PNAs
> do not clip correctly, and in any case the polygon fill rendering (e.g.
> for airspace) when the bounds are outside was known to fail before we
> implemented our own clipping system.  It has to be restored.

It's documented that GDI will clip (if you pass the according options
to CreateWindow()).  Is that a known GDI bug?  Which Windows versions
are affected?  Which drawing functions are affected, under which
circumstances?  Did anyone report that bug to Microsoft?  What was the
response?

Max

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Xcsoar-devel mailing list
Xcsoar-devel@...
https://lists.sourceforge.net/lists/listinfo/xcsoar-devel

[John Wharington-2]

On Tue, 2009-09-22 at 15:48 +0200, Max Kellermann wrote:

> On 2009/09/22 15:43, John Wharington <jwharington@...> wrote:
> > Unfortunately GDI does NOT do all the clipping work.  Several PDA/PNAs
> > do not clip correctly, and in any case the polygon fill rendering (e.g.
> > for airspace) when the bounds are outside was known to fail before we
> > implemented our own clipping system.  It has to be restored.
>
> It's documented that GDI will clip (if you pass the according options
> to CreateWindow()).  Is that a known GDI bug?  Which Windows versions
> are affected?  Which drawing functions are affected, under which
> circumstances?  Did anyone report that bug to Microsoft?  What was the
> response?
>

Have a look through the mailing list archives if you don't believe me.
It's probably not a problem with GDI per se, but rather, vendor-specific
device drivers.  That's for line clipping.  For polygon clipping, we
needed to implement it rather early in XCSoar's development.  If you are
deep inside an airspace region (or AAT sector), then without our
clipping, the fill pattern is invisible.

No-one to my knowledge has reported it to microsoft, and it doesn't
matter much anyway since a large proportion of our users have PDAs that
do not have OS updates available offered (nor could we demand that they
pay money for such updates just in order to use XCSoar).




------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Xcsoar-devel mailing list
Xcsoar-devel@...
https://lists.sourceforge.net/lists/listinfo/xcsoar-devel

[Max Kellermann]

On 2009/09/22 15:48, Max Kellermann <max@...> wrote:
> It's documented that GDI will clip (if you pass the according options
> to CreateWindow()).  Is that a known GDI bug?  Which Windows versions
> are affected?  Which drawing functions are affected, under which
> circumstances?  Did anyone report that bug to Microsoft?  What was the
> response?

By the way - until a month ago, the MapWindow always occupied the full
screen, even if not in full-screen mode.  This mean, that
WS_CLIPSIBLINGS needs to work properly, because the InfoBoxes are
siblings of MapWindow, "above" it in the z-order.

If there was a clipping bug, I think the symptoms might be gone now,
since we don't rely on WS_CLIPSIBLINGS anymore.  That is, except for
the menu buttons and dialogs, because those were not considered by
XCSoar's custom clipping code anyway.

However I don't think this really affects us at all, because we're
drawing to a buffer, not directly to a window on the screen.  When you
observed that bug, did XCSoar already buffer the MapWindow?

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Xcsoar-devel mailing list
Xcsoar-devel@...
https://lists.sourceforge.net/lists/listinfo/xcsoar-devel

[John Wharington-2]

On Tue, 2009-09-22 at 16:00 +0200, Max Kellermann wrote:

> On 2009/09/22 15:48, Max Kellermann <max@...> wrote:
> > It's documented that GDI will clip (if you pass the according options
> > to CreateWindow()).  Is that a known GDI bug?  Which Windows versions
> > are affected?  Which drawing functions are affected, under which
> > circumstances?  Did anyone report that bug to Microsoft?  What was the
> > response?
>
> By the way - until a month ago, the MapWindow always occupied the full
> screen, even if not in full-screen mode.  This mean, that
> WS_CLIPSIBLINGS needs to work properly, because the InfoBoxes are
> siblings of MapWindow, "above" it in the z-order.
>
> If there was a clipping bug, I think the symptoms might be gone now,
> since we don't rely on WS_CLIPSIBLINGS anymore.  That is, except for
> the menu buttons and dialogs, because those were not considered by
> XCSoar's custom clipping code anyway.
>
> However I don't think this really affects us at all, because we're
> drawing to a buffer, not directly to a window on the screen.  When you
> observed that bug, did XCSoar already buffer the MapWindow?

These observed bugs were historical (i.e. 5.2.4 and earlier).  We will
need to assess them again now.  Test cases should include drawing a
polygon that is much larger than (and entirely including) the view port,
and partial visibilities.




------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Xcsoar-devel mailing list
Xcsoar-devel@...
https://lists.sourceforge.net/lists/listinfo/xcsoar-devel

[Max Kellermann]

On 2009/09/22 16:22, John Wharington <jwharington@...> wrote:
> These observed bugs were historical (i.e. 5.2.4 and earlier).  We will
> need to assess them again now.  Test cases should include drawing a
> polygon that is much larger than (and entirely including) the view port,
> and partial visibilities.

Note the RunPaintCanvas test program I submitted.  We can easily add a
polygon/clipping test program.

In the mail archive, I read that HP 31x are affected by that bug.
Have you got one to test with?

Max

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Xcsoar-devel mailing list
Xcsoar-devel@...
https://lists.sourceforge.net/lists/listinfo/xcsoar-devel

[John Wharington-2]

On Tue, 2009-09-22 at 16:24 +0200, Max Kellermann wrote:

> On 2009/09/22 16:22, John Wharington <jwharington@...> wrote:
> > These observed bugs were historical (i.e. 5.2.4 and earlier).  We will
> > need to assess them again now.  Test cases should include drawing a
> > polygon that is much larger than (and entirely including) the view port,
> > and partial visibilities.
>
> Note the RunPaintCanvas test program I submitted.  We can easily add a
> polygon/clipping test program.
>
> In the mail archive, I read that HP 31x are affected by that bug.
> Have you got one to test with?

I don't have one, no.  But my father does (birthday present last
year ;-).




------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Xcsoar-devel mailing list
Xcsoar-devel@...
https://lists.sourceforge.net/lists/listinfo/xcsoar-devel