Without analyzing callers it's tough for me to say what most code assumes here. I know event dispatch certainly wants transformed bounds. I definitely see the use case for both. I would be inclined to have Transformed and Untransformed in the name to make it clear which is which.

I don't have a strong opinion. I would not expect the code snippet in the description to move the window.

If the most common case is no-transform, I would be OK with GetBoundsInScreen() and GetBoundsInScreenTransformed(). If there's a lot of use of both cases, then sky's suggestion of Transformed/Untransformed makes sense to me. Either way it would be useful to have comments explaining with some examples of when a transform might exist.

> I know event dispatch certainly wants transformed bounds.

Event dispatch transform the event location but not the bounds. This only transform the origin, so event dispatching can't use this (and gfx:Rect can't always be transform to gfx::Rect, say rotated 45deg)

This is the reason why I wonder if this is really useful.

As a first step, I'll try CL on bots to see how many *tests* depends on this behavior.

One correction in my example:

SetBoundsInScreen applies the transform before setting the bounds, so that example actually works,
because both path (get/set) does same transform only to the origin. What didn't work in my testing
was Window::SetBounds() with assumption that parent's origin is same as root.

This still have a issue, as we may save this bounds with transform, then reapply later without transform.

I'll run test next week.