Opened 5 years ago

Closed 4 years ago

#11769 closed defect (fixed)

wxPython GraphicsContext.Scale moves (0, 0)

Reported by: steveward Owned by: csomor
Priority: normal Milestone:
Component: GUI-all Version: 2.8.10
Keywords: GraphicsContext Scale wxMac wxMSW Cc: ward@…, csomor
Blocked By: Blocking:
Patch: no

Description

Presumably a call to GraphicsContext.Scale(xscale, yscale) should scale subsequently drawn graphics but should not move the origin, (0,0). I've
found that a Scale call does seem to move the origin for subsequent graphics, at least on OSX 10.6.2 using the current binary wxpython distribution.

The attached program draws a simple graphic at (0, 0) in a gc, then scales the gc and re-draws the graphic. The two versions are misaligned by a few pixels; the offset seems proportional to the args to Scale, but the constant of proportionality isn't obvious.

The matrix reports that (0, 0) has not been moved, but for some reason the
origin of the graphics move. Is there some kind of margin that's scaled and offsets the graphics?

In any case this seems like a bug, but apologies if I'm doing something stupid.
I've attached the little test program and a screen shot of its window.

Attachments (2)

gcbug_pix.png download (17.9 KB) - added by steveward 5 years ago.
Screenshot
gcbug01.py download (2.1 KB) - added by steveward 5 years ago.
program that demos the bug

Download all attachments as: .zip

Change History (7)

Changed 5 years ago by steveward

Screenshot

Changed 5 years ago by steveward

program that demos the bug

comment:1 Changed 5 years ago by robind

  • Cc csomor added
  • Component changed from wxPython to GUI-all
  • Keywords wxMac wxMSW added
  • Status changed from new to confirmed

I'm not sure why this is happening or even if it is right or wrong, but I can confirm that it also happens on wxMSW with GDI+ with the exact same results as wxMac. On wxGTK the circles align as expected. It also happens in 2.9 trunk in at least wxOSX-cocoa.

Stefan, do you have any ideas about this?

comment:2 Changed 5 years ago by steveward

WORKAROUND:

I have experimentally determined that the following replacement
for calls to gc.Scale(DX, DY) fixes the problem, to a good first
order:

# My workaround for the GraphicsContext.Scale Bug:
def GCScale(gc, DX, DY):

gc.Scale(DX, DY)
gc.Translate(-(DX-1.0)/(2.0*DX), -(DY-1.0)/(2.0*DY))

This may give someone who knows the code well a clue as
to the bug. In any case, it provides a temporary, albeit
ugly, work-around...

comment:3 Changed 5 years ago by csomor

  • Owner set to csomor
  • Status changed from confirmed to accepted

it's the ShouldOffset that return true here, although when scaling this all doesn't make sense anymore

comment:4 Changed 5 years ago by SC

(In [63590]) translate 0.5 offset into user space before applying translation, see #11769, see #11771

comment:5 Changed 4 years ago by csomor

  • Resolution set to fixed
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.