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

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

>>>>> On Thu, 15 Jul 2010 09:50:05 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

>> 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?

> No, just that placing of tooltips is very common and just one of
> those things that does f->left_pos + some offset.

>>> 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)'.

> I think your "only" is quite big.  Lots of code, C and Lisp, does
> that kind of calculation.

In what sense can they be simplified if we used absolute scaled
coordinate in Lisp as you say?  Window system APIs requires us to
specify absolute unscaled coordinates when creating windows or popup
menus, so some conversions are necessary anyway.

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