DrawEllipticArc broken on windows?

If I change line 112 of ScrolledWindow.py in the wxPython demo to:

        dc.DrawEllipticArc(200,500, 50,75, 0, -90)

i.e. the last value changed from 90 to -90 -- on Linux I get what I
expect: a 90 degree wedge (i.e. clockwise from 3 o'clock to 6
o'clock). On windows, I get three-fourths of a pie: counterclockwise
from 3 o'clock to 6 o'clock.

According to the wx docs, the Linux version is correct. This is in
2.8.6.0... too late to get a fix in for 2.8.6.1?

Rob

Rob,

FWIW, the enclosed PNG is what I get on OS-X (wxPython 2.8.4)

I've also enclosed the test code.

-Chris

Arc.png

EllipticArcTest.py (917 Bytes)

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Thanks for the test code. It's weird: all 3 platforms are different!
Enclosed are gtk and win, both 2.8.6.0

The wxWidgets docs implies that gtk would be considered correct -- it
says the "current brush is used for drawing the pie". I'm assuming
"pie" is the standard definition of what a pie-shaped piece looks
like. :slight_smile:

Rob

PS: I noticed this problem because the minor mode I wrote to be the
tutorial for peppy is a smiley face -- it's a frown on windows!

···

On 10/18/07, Christopher Barker <Chris.Barker@noaa.gov> wrote:

FWIW, the enclosed PNG is what I get on OS-X (wxPython 2.8.4)

Rob McMullen wrote:

Thanks for the test code. It's weird: all 3 platforms are different!
Enclosed are gtk and win, both 2.8.6.0

The wxWidgets docs implies that gtk would be considered correct -- it
says the "current brush is used for drawing the pie". I'm assuming
"pie" is the standard definition of what a pie-shaped piece looks
like. :slight_smile:

Well, it's question of how you define a 0 to -90 arc -- -90d == +270d, so it looks like Windows is doing that translation, then drawing it.

wxWidgets should be consistent here though.

Did you try DC.DrawArc? it may work better.

-CHB

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

It turns out Windows always draws arcs counterclockwise, so wxWidgets
needs to swap its start and end coordinates when it wants to draw
clockwise. I found this reference in the MSW docs at

"The curve of the pie is defined by an ellipse that fits the specified
bounding rectangle. The curve begins at the point where the ellipse
intersects the first radial and extends counterclockwise to the point
where the ellipse intersects the second radial."

Looking through the wxWidgets method wxDC::DoDrawEllipticArc in msw/dc.cpp:

it does just what you say: interprets -90 as 270, so instead of 0, -90
drawing a clockwise arc from 0 to -90, it draws a counterclockwise arc
from 0 to 270. It should be modified to draw a counterclockwise arc
from 270 to 0 in that case. I can't compile on windows, so I can't
test a fix, but regardless, it's an inconsistency in wxWidgets, not
wxPython, so I'll file a bug report on sf.

Rob

···

On 10/18/07, Christopher Barker <Chris.Barker@noaa.gov> wrote:

Well, it's question of how you define a 0 to -90 arc -- -90d == +270d,
so it looks like Windows is doing that translation, then drawing it.

Rob McMullen wrote:

···

On 10/18/07, Christopher Barker <Chris.Barker@noaa.gov> wrote:

FWIW, the enclosed PNG is what I get on OS-X (wxPython 2.8.4)

Thanks for the test code. It's weird: all 3 platforms are different!

OS X is different because it is using wxGraphicsContext underneath. If you switch the sample to using wx.GCDC then they are all the same, but I expect that they should all be considered wrong.

I'll take a look at the patch you submitted to SF.

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!