Then I went "Ahhhhhhh" the true origin of the graphics context is that of the clip rect, and it is translating the origin back to where it should be for the whole component.. I must be undoing that correction....
That is what I THINK is happening, since if you try moving another (heavyweight) window over the stretched window, and then click/focus on the stretched window to bring it to the front, you would notice that the transformed image is actually drawn with a translation similar in size to the distance between the left edges of the two windows.
Again, my guess is that the Swing renderer:
1. Is notified of a paint() request by the native paint sub-system to repaint the dirty regions
2. calls Graphics.create(int x, int y, int width, int height) to get a "sub" Graphics object with a new clip and origin (and adjusts the translation to reflect the original Graphics origin) and propagates that "sub" Graphics object down the paint() heirachy instead.
I'm very curious as to why they didn't just clip the original Graphics object if that's the case

.
Is that behaviour documented?

?
I haven't seen any myself, therefore I can only make reasonable speculations. Hopefully someone else can confirm.
Maybe it's only a Swing quirk. Does AWT work differently?