bug#5721: Feature request: Function that returns absolute coordinates

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

>>>>> On Thu, 15 Jul 2010 08:07:26 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

>>> I would imagine that for frame positioning, absolute scaled would
>>> be the default, as top and left frame parameters should also be
>>> absolute scaled.
>> 
>> That would bring us coarser precision with respect to the frame
>> position.  If the scale factor is 2, then we cannot place a frame
>> to a position whose coordinate is an odd number (in absolute
>> unscaled).

> As I said below, special functions to do that based on unscaled
> coordinates would be needed.  But for the default scaled should be
> used.

It's the source of complication to divide absolute into scaled and
unscaled (the latter is required anyway because window system APIs
require that).  It's much simpler and cleaner to consider that
absolute is alway unscaled and relative is always scaled.

> Placing tooltips for example is much more common than placing
> frames.  Doing so based on scaled coordinates is no problem.

I don't understand how placement of tooltips and frames are different.
The documentation of tooltip-frame-parameters says `left' and `top' is
specified with absolute position.  Do you mean assigning different
meanings to these frame parameters depending on whether it is for a
tooltip or for a usual frame?

> The alternative, to use unscaled, would make Emacs internals
> everywhere have to handle two coordinate systems all the time.  To
> knowingly introduce such an overhead on everything is madness.

The Mac port already takes account of scaling factor with the policy I
explained.  That means no change is necessary for the platform
independent part.  The conversion is necessary only when the current
X11 code is using the "idiom"s like `x += f->left_pos +
FRAME_OUTER_TO_INNER_DIFF_X (f)'.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp