more bugs in the GCDC code

wxPython Users
1

here is a small sample that demonstrates some errors in the GCDC code.
As you slide the slider… the EllipticArc becomes thiner but the point where it begins is not what I indicated (it appears that it becomes horizontally shorter too)

If you comment out the GCDC wrapper the EllipticArc behaves as expected.

import wx

class Canvas(wx.Panel):
def init(self, parent):
wx.Panel.init(self, parent)
self.Bind
(wx.EVT_PAINT, self.OnPaint)
self.bkg_brush = wx.Brush((190,190,255))
self.v_pos = 100

def OnPaint(self, evt):
    dc = wx.PaintDC(self)
    dc = wx.GCDC(dc)
    dc.SetBackground(self.bkg_brush)
    dc.Clear()
    dc.DrawEllipticArc(100, 200, 200, 150-self.v_pos, 90,270)
    dc.DrawLine(100, 100, 100, 300)

class MyFrame(wx.Frame):
def init(self):

    wx.Frame.__init__(self, None, title="OffestError")
    self.SetSize((640,480))
    self.canvas = Canvas(self)
    self.slider = wx.Slider(self, minValue=0, maxValue=47)
    box = wx.BoxSizer(wx.VERTICAL)
    box.Add(self.canvas, 1, wx.EXPAND)
    box.Add(self.slider, 0, wx.EXPAND)
    self.SetSizer(box)
    self.Show()
    self.CenterOnScreen()
    self.slider.Bind

(wx.EVT_SLIDER, self.OnSlide)

def OnSlide(self, evt):
    self.canvas.v_pos = 100+self.slider.GetValue()
    self.canvas.Refresh(False)

if name == “main”:
app = wx.App(0)
frame = MyFrame()
app.MainLoop()

···

–
There is NO FATE, we are the creators.

2

More findings: the error seams to appear only for uneven heights.

Peter

···

–
There is NO FATE, we are the creators.

3

Peter Damoc wrote:

here is a small sample that demonstrates some errors in the GCDC code.
As you slide the slider... the EllipticArc becomes thiner but the point where it begins is not what I indicated (it appears that it becomes horizontally shorter too)
If you comment out the GCDC wrapper the EllipticArc behaves as expected.

My guess is that it has to do with rounding errors as it is converted to floating point coordinates for the path. I'll fiddle with the code to see if I can get a better result.

Thanks for the sample.

···

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

4

Robin Dunn wrote:

Peter Damoc wrote:

here is a small sample that demonstrates some errors in the GCDC code.
As you slide the slider... the EllipticArc becomes thiner but the point where it begins is not what I indicated (it appears that it becomes horizontally shorter too)
If you comment out the GCDC wrapper the EllipticArc behaves as expected.

My guess is that it has to do with rounding errors as it is converted to floating point coordinates for the path. I'll fiddle with the code to see if I can get a better result.

I checked in a change for this that gives pretty good results. I also removed the code that was closing the ends of the arc's path since the DC version didn't do that.

BTW, in case you're interested the code to implement wxGCDC::DrawEllipticArc using the graphics context and path classes looks like this:

     wxGraphicsPath path = m_graphicContext->CreatePath();
     m_graphicContext->PushState();
     m_graphicContext->Translate(x+w/2.0,y+h/2.0);
     wxDouble factor = ((wxDouble) w) / h;
     m_graphicContext->Scale( factor , 1.0);

     // since these angles (ea,sa) are measured counter-clockwise, we invert them to
     // get clockwise angles
     path.AddArc( 0, 0, h/2.0 , DegToRad(-sa) , DegToRad(-ea), sa > ea );
     m_graphicContext->DrawPath( path );
     m_graphicContext->PopState();

···

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

5

Thanks Robin,

I managed to circumvent the bug by using even numbers and since my boss is pleased with the result… I guess I’ll just wait for the next release :wink:

Peter

···

On 2/23/07, Robin Dunn robin@alldunn.com wrote:

Robin Dunn wrote:

Peter Damoc wrote:

here is a small sample that demonstrates some errors in the GCDC code.
As you slide the slider… the EllipticArc becomes thiner but the
point where it begins is not what I indicated (it appears that it

becomes horizontally shorter too)
If you comment out the GCDC wrapper the EllipticArc behaves as expected.

My guess is that it has to do with rounding errors as it is converted to

floating point coordinates for the path. I’ll fiddle with the code to
see if I can get a better result.

I checked in a change for this that gives pretty good results. I also
removed the code that was closing the ends of the arc’s path since the

DC version didn’t do that.

BTW, in case you’re interested the code to implement
wxGCDC::DrawEllipticArc using the graphics context and path classes
looks like this:

 wxGraphicsPath path = m_graphicContext->CreatePath();

 m_graphicContext->PushState();
 m_graphicContext->Translate(x+w/2.0,y+h/2.0);
 wxDouble factor = ((wxDouble) w) / h;
 m_graphicContext->Scale( factor , 1.0);

 // since these angles (ea,sa) are measured counter-clockwise, we

invert them to
// get clockwise angles
path.AddArc( 0, 0, h/2.0 , DegToRad(-sa) , DegToRad(-ea), sa > ea );
m_graphicContext->DrawPath( path );
m_graphicContext->PopState();

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

To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail:
wxPython-users-help@lists.wxwidgets.org

–
There is NO FATE, we are the creators.