tcl-core

[TCLCORE] Purpose of mmObjType vs pixelObjType

[Alexandre F. <ale...@gm...>]

Hi,

In the absence of reaction to my question "Why millimeters", I have
spent several minutes in apnea in tkObj.c et al.
Now I am really perplex. I have the impression that:

     - pixelObjType is the primary multi-unit storage type. It holds a
double internal value, and an integer "returnValue".

     - mmObjType is a secondary type with roughly the same properties,
the only differences being the interpretation (scale) of the double
value *and* the fact that the returnValue is double too.

     - in tkObj.c the code comments are completely confusing because
they are visibly copied/pasted from the pixelObjType, and frequently
misuse the word "pixel" where "mm" is meant.

    - I cannot seem to find a documentation page giving the contracts
nor even rationale for these types. Something like "the unit is
sticky" or "no loss of precision while staying iso-unit", or the
like...

Can you help me there ? I have the vague impression that the initial
problem in tkCanvUtil.c (useless roundtrip to mm for [coords]) would
be trivially avoided by using the pixel type (especially the
GetDoublePixels variant, which does not go through the integer
bottleneck) and not the MM type. But the problem is that this would
completely void the usefulness of the MM type (the other use is in
text tabs; similar migration could be done harmlessly I guess)...

What am I missing ?

Thanks in advance,

-Alex

Re: [TCLCORE] Purpose of mmObjType vs pixelObjType

[Kevin K. <ke...@ac...>]

Alexandre Ferrieux wrote:
[regarding pixelObjType and  mmObjType]

>     - I cannot seem to find a documentation page giving the contracts
> nor even rationale for these types. Something like "the unit is
> sticky" or "no loss of precision while staying iso-unit", or the
> like...

I don't know all the history, but let me try to start from the other
end.

Tk, by design, tried very hard to keep all measurements in millimetres,
because doing so had some chance at keeping more or less the same
appearance of a GUI at all screen resolutions. Then as now, there was
a problem otherwise that points, mm, and pixels were all freely
intermixed; people would specify, say, the size of a text in points,
but the size of the container that it went in in pixels (or vice versa),
yielding proportions that were sometimes ludicrously bad (a microscopic
label on a huge component, or worse, a label cut off by the borders
of its component).

This convention caused a lot of expense in the time when everything
was a string in implementation as well as concept; screen measurements
had to have their numeric parts scanned, their units recognized, and
then be converted to mm.  For this reason screen measurements were
among the first Tk things to be converted to custom Tcl_Obj's.

Since even the unit conversions were expensive (floating point
dividers were *slow* in the early 1990's), objects representing
both millimetres and pixels were implemented.  These objects, like
all Tcl objects, tended freely to shimmer. An object simply had
whatever representation was requested last.

At the time, little attention was paid to floating point accuracy.
Tcl was slow enough that anyone doing serious numeric calculations
resorted to C. It took quite a while to discover the subtle yet
pernicious bugs that result when floating point conversion is not
handled with full precision. (Situations where ($a != $b) while
($a eq $b) are nightmares. Such behaviour is acceptable only
for NaN, and grudgingly so.) Those bugs led Don Porter and me to
rework Tcl's floating point conversions, ensuring that the
string and internal representations of 'double' objects always
agree. (Tcl got bignums almost as a side effect. Bignum arithmetic
was needed for the floating point calculations, so why not
expose bignums at Tcl level too?)

This effort stopped with Tcl. Don and I had a look at Tk, plucked
a small amount of low-hanging fruit, and decided that neither of
us really had the time to delve into how Tk uses and converts
floating point numbers. I'm entirely unsurprised that there are
remaining bugs. At the time that the screen measurement object
types were implemented, people simply didn't care. I'm also
convinced that the bugs are mostly benign; at the end of the
calculation, they result in sub-pixel differences to screen objects.
Where they do cause trouble is in applications where people need
lossless conversion, expecting to get the same number out that
they put in.

Lossless conversion isn't possible or desirable in all cases,
of course.  Someone who, for example, scales an object on a
canvas by a factor of 0.1 and then scales the result by 10.0
is not going to get the same object back. It's not going to
happen.  But for simple arithmetic on the screen metrics, it
probably should.

One possibility - I don't know how reasonable this would be -
would be to carry screen dimensions over the lowest common
denominator of points (or Microsoft's twentieths-of-points?),
mm (or microns, perhaps?) and pixels.  Such a representation
would be an integer almost all of the time, perhaps yielding
less chance of losing precision on the way.

The key contract that Tcl tries to keep for numbers is:
"If ($a eq $b), then ($a == $b) with the single exception
of NaN."  The chief objective of all the numeric changes in
8.5 was to make that statement true at long last. I would
imagine that 'pixelObjType' and 'mmObjType', while they
don't enter into == comparisons, need a similar contract
about the internal representation matching the string.

Tcl's numbers, since 8.5, achieve that in part by having
internal representations that are sticky in the sense that
if an object represents an integer, e.g. "123",
Tcl_GetDoubleFromObj will cache the internal representation
of an integer - not a double.  The idea that "the unit is
sticky" might be a means to that end.

I know, I've made things less clear, not more -- but it's
important to remember that some of these things Just
Happened.

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] Purpose of mmObjType vs pixelObjType

[Alexandre F. <ale...@gm...>]

On Mon, Nov 10, 2008 at 4:57 PM, Kevin Kenny <ke...@ac...> wrote:
>
> [regarding pixelObjType and  mmObjType]

Thanks for the perspective Kevin. It dissipates a finite (as in :
nonzero) proportion of the mystery ;-)

> Tk, by design, tried very hard to keep all measurements in millimetres,
> because doing so had some chance at keeping more or less the same
> appearance of a GUI at all screen resolutions.

Of course. But this only mandates the possibility (which is present
today) of providing all screen distances in you preferred unit. In
string world this is a piece o'cake (1mm, 2i, 3cm).
This does *not* tell anything about how things should be handled
internally though. The very same external contract can be fulfilled
with several alternative implementation choices...

> both millimetres and pixels were implemented.  These objects, like
> all Tcl objects, tended freely to shimmer. An object simply had
> whatever representation was requested last.

What's funny is that in today's [coords] issue, pure Tcl_ObjType-based
lazy conversion would handle the job better than the actual code.
As it turns out, [coords] is fed distances in pixels (meaning that
numbers without decoration are interpreted as pixels), and when
requested to spit them back out it must also give back pixels. Here it
turns out that there is a parasitic quasi-shimmering (not even a true
one) to millimeters. But contrarily to other situations there is no
good reasons to shimmer, since nobody on the data path is client of
the millimeter form !

> Lossless conversion isn't possible or desirable in all cases,
> of course.  Someone who, for example, scales an object on a
> canvas by a factor of 0.1 and then scales the result by 10.0
> is not going to get the same object back. It's not going to
> happen.  But for simple arithmetic on the screen metrics, it
> probably should.

Yes it should. Store-and-retrieve, in the natural unit of the canvas
which is the pixel, should be a no-op.

> One possibility - I don't know how reasonable this would be -
> would be to carry screen dimensions over the lowest common
> denominator of points (or Microsoft's twentieths-of-points?),
> mm (or microns, perhaps?) and pixels.  Such a representation
> would be an integer almost all of the time, perhaps yielding
> less chance of losing precision on the way.

You're aiming higher than I was :-)

I'm working with the naive idea that as soon as a screen distance is
provided with decoration (letters giving a unit), all claims of
losslessness are lost, while naked numbers (integers or
floating-point) should be protected as much as possible.
This approach doesn't need to resort to integer-numbers-of-common-subunit.

> I know, I've made things less clear, not more -- but it's
> important to remember that some of these things Just
> Happened.

I propose to just patch Tk_CanvasGetCoordFromObj so that it calls
GetDoublePixels instead of the current shenanigans.
Any objection ?

-Alex

Re: [TCLCORE] Purpose of mmObjType vs pixelObjType

[Donal K. F. <don...@ma...>]

Alexandre Ferrieux wrote:
> I propose to just patch Tk_CanvasGetCoordFromObj so that it calls
> GetDoublePixels instead of the current shenanigans.
> Any objection ?

It's worth trying and seeing what blows up in the test suite. And then
deciding whether the answer that the test suite was looking for was the
right thing or not. (I suspect that getting rid of the shenanigans will
be a good thing, but let's double-check that...)

Donal.

Re: [TCLCORE] Purpose of mmObjType vs pixelObjType

[Alexandre F. <ale...@gm...>]

On Mon, Nov 10, 2008 at 6:57 PM, Donal K. Fellows
<don...@ma...> wrote:
> Alexandre Ferrieux wrote:
>>
>> I propose to just patch Tk_CanvasGetCoordFromObj so that it calls
>> GetDoublePixels instead of the current shenanigans.
>> Any objection ?
>
> It's worth trying and seeing what blows up in the test suite. And then
> deciding whether the answer that the test suite was looking for was the
> right thing or not. (I suspect that getting rid of the shenanigans will
> be a good thing, but let's double-check that...)

Ready to do so; however right now HEAD has a bunch (12) of Tk test
failures (XP SP2):

==== bind-22.10 HandleEventGenerate FAILED
==== bind-22.10 FAILED
==== frame-2.8 toplevel configuration options FAILED
==== frame-2.8 FAILED
==== text-19.16 DeleteChars procedure, updates affecting topIndex FAILED
==== text-19.16 FAILED
==== text-33.11 peer widget -start, -end FAILED
==== text-33.11 FAILED
==== textDisp-29.2 miscellaneous: lines wrap but are still too long FAILED
==== textDisp-29.2 FAILED
==== textDisp-29.2.1 miscellaneous: lines wrap but are still too long FAILED
==== textDisp-29.2.1 FAILED
==== textDisp-29.2.2 miscellaneous: lines wrap but are still too long FAILED
==== textDisp-29.2.2 FAILED
==== textDisp-29.2.3 miscellaneous: lines wrap but are still too long FAILED
==== textDisp-29.2.3 FAILED
==== textDisp-29.2.4 miscellaneous: lines wrap but are still too long FAILED
==== textDisp-29.2.4 FAILED
==== textDisp-32.2 elide and tags FAILED
==== textDisp-32.2 FAILED
==== textImage-3.2 delayed image management FAILED
==== textImage-3.2 FAILED
==== + winDialog-1.1 hanging (bgerror window saying :

    while executing
"testwinevent $::tk_dialog $button WM_LBUTTONDOWN 1 0x000a000b"
    (procedure "Click" line 2)

Yes, the error string is _empty_).

Am I alone to witness all this ?
I hesitate to fiddle with the coordinate system with such a background...

Re: [TCLCORE] Purpose of mmObjType vs pixelObjType

[Pat T. <pat...@us...>]

"Alexandre Ferrieux" <ale...@gm...> writes:

>On Mon, Nov 10, 2008 at 6:57 PM, Donal K. Fellows
><don...@ma...> wrote:
>> Alexandre Ferrieux wrote:
>>>
>>> I propose to just patch Tk_CanvasGetCoordFromObj so that it calls
>>> GetDoublePixels instead of the current shenanigans.
>>> Any objection ?
>>
>> It's worth trying and seeing what blows up in the test suite. And then
>> deciding whether the answer that the test suite was looking for was the
>> right thing or not. (I suspect that getting rid of the shenanigans will
>> be a good thing, but let's double-check that...)
>
>Ready to do so; however right now HEAD has a bunch (12) of Tk test
>failures (XP SP2):
>
>==== bind-22.10 HandleEventGenerate FAILED
>==== bind-22.10 FAILED
>==== frame-2.8 toplevel configuration options FAILED
>==== frame-2.8 FAILED
>==== text-19.16 DeleteChars procedure, updates affecting topIndex FAILED
>==== text-19.16 FAILED
>==== text-33.11 peer widget -start, -end FAILED
>==== text-33.11 FAILED
>==== textDisp-29.2 miscellaneous: lines wrap but are still too long FAILED
>==== textDisp-29.2 FAILED
>==== textDisp-29.2.1 miscellaneous: lines wrap but are still too long FAILED
>==== textDisp-29.2.1 FAILED
>==== textDisp-29.2.2 miscellaneous: lines wrap but are still too long FAILED
>==== textDisp-29.2.2 FAILED
>==== textDisp-29.2.3 miscellaneous: lines wrap but are still too long FAILED
>==== textDisp-29.2.3 FAILED
>==== textDisp-29.2.4 miscellaneous: lines wrap but are still too long FAILED
>==== textDisp-29.2.4 FAILED
>==== textDisp-32.2 elide and tags FAILED
>==== textDisp-32.2 FAILED
>==== textImage-3.2 delayed image management FAILED
>==== textImage-3.2 FAILED
>==== + winDialog-1.1 hanging (bgerror window saying :
>
>    while executing
>"testwinevent $::tk_dialog $button WM_LBUTTONDOWN 1 0x000a000b"
>    (procedure "Click" line 2)
>
>Yes, the error string is _empty_).
>
>Am I alone to witness all this ?
>I hesitate to fiddle with the coordinate system with such a background...

I get some text widget failures and 2 canvas fails. I certainly dont
see the winDialog one. Is that always happening for you? If so are you
using a non-English version of windows or something other than XP
maybe?

On WindowsXP I dont see failures for bind or frame.

-- 
Pat Thoyts                            http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD

Re: [TCLCORE] Purpose of mmObjType vs pixelObjType

[Alexandre F. <ale...@gm...>]

On Wed, Nov 12, 2008 at 12:22 AM, Pat Thoyts
<pat...@us...> wrote:
> "Alexandre Ferrieux" <ale...@gm...> writes:
>
>>On Mon, Nov 10, 2008 at 6:57 PM, Donal K. Fellows
>><don...@ma...> wrote:
>>> Alexandre Ferrieux wrote:
>>>>
>>>> I propose to just patch Tk_CanvasGetCoordFromObj so that it calls
>>>> GetDoublePixels instead of the current shenanigans.
>>>> Any objection ?
>>>
>>> It's worth trying and seeing what blows up in the test suite. And then
>>> deciding whether the answer that the test suite was looking for was the
>>> right thing or not. (I suspect that getting rid of the shenanigans will
>>> be a good thing, but let's double-check that...)
>>
>>Ready to do so; however right now HEAD has a bunch (12) of Tk test
>>failures (XP SP2):
>>
>>==== bind-22.10 HandleEventGenerate FAILED
>>==== bind-22.10 FAILED
>>==== frame-2.8 toplevel configuration options FAILED
>>==== frame-2.8 FAILED
>>==== text-19.16 DeleteChars procedure, updates affecting topIndex FAILED
>>==== text-19.16 FAILED
>>==== text-33.11 peer widget -start, -end FAILED
>>==== text-33.11 FAILED
>>==== textDisp-29.2 miscellaneous: lines wrap but are still too long FAILED
>>==== textDisp-29.2 FAILED
>>==== textDisp-29.2.1 miscellaneous: lines wrap but are still too long FAILED
>>==== textDisp-29.2.1 FAILED
>>==== textDisp-29.2.2 miscellaneous: lines wrap but are still too long FAILED
>>==== textDisp-29.2.2 FAILED
>>==== textDisp-29.2.3 miscellaneous: lines wrap but are still too long FAILED
>>==== textDisp-29.2.3 FAILED
>>==== textDisp-29.2.4 miscellaneous: lines wrap but are still too long FAILED
>>==== textDisp-29.2.4 FAILED
>>==== textDisp-32.2 elide and tags FAILED
>>==== textDisp-32.2 FAILED
>>==== textImage-3.2 delayed image management FAILED
>>==== textImage-3.2 FAILED
>>==== + winDialog-1.1 hanging (bgerror window saying :
>>
>>    while executing
>>"testwinevent $::tk_dialog $button WM_LBUTTONDOWN 1 0x000a000b"
>>    (procedure "Click" line 2)
>>
>>Yes, the error string is _empty_).
>>
>>Am I alone to witness all this ?
>>I hesitate to fiddle with the coordinate system with such a background...
>
> I get some text widget failures and 2 canvas fails. I certainly dont
> see the winDialog one. Is that always happening for you? If so are you
> using a non-English version of windows or something other than XP
> maybe?

Yes, it is deterministic :-(
Yes, I'm using a French version of Windows, but is it an excuse ?
As I said, it is Windows XP SP2...

-Alex

Re: [TCLCORE] Purpose of mmObjType vs pixelObjType

[Pat T. <pat...@us...>]

"Alexandre Ferrieux" <ale...@gm...> writes:

>>>==== + winDialog-1.1 hanging (bgerror window saying :
>>>
>>>    while executing
>>>"testwinevent $::tk_dialog $button WM_LBUTTONDOWN 1 0x000a000b"
>>>    (procedure "Click" line 2)
>>>
>>>Yes, the error string is _empty_).
>>>
>>>Am I alone to witness all this ?
>>>I hesitate to fiddle with the coordinate system with such a background...
>>
>> I get some text widget failures and 2 canvas fails. I certainly dont
>> see the winDialog one. Is that always happening for you? If so are you
>> using a non-English version of windows or something other than XP
>> maybe?
>
>Yes, it is deterministic :-(
>Yes, I'm using a French version of Windows, but is it an excuse ?
>As I said, it is Windows XP SP2...

Its not an excuse but an additional data point. Its possible, although
not likely, that the resource ID used for that button on that dialog
is different for non-English versions of windows. If so then a
constraint needs to be added.
However, checking the resources in comdlg32.dll - the Annuler button
has the same ID (2) as the Cancel button in the English locale. In
fact OK and Cancel are standard ids - I cant think of any reason why
winDialog-1.1 should fail for you and not for me. You probably should
raise a bug, Very strange.

-- 
Pat Thoyts                            http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD

Re: [TCLCORE] Purpose of mmObjType vs pixelObjType

[Alexandre F. <ale...@gm...>]

On Mon, Nov 10, 2008 at 6:57 PM, Donal K. Fellows
<don...@ma...> wrote:
> Alexandre Ferrieux wrote:
>>
>> I propose to just patch Tk_CanvasGetCoordFromObj so that it calls
>> GetDoublePixels instead of the current shenanigans.
>> Any objection ?
>
> It's worth trying and seeing what blows up in the test suite. And then
> deciding whether the answer that the test suite was looking for was the
> right thing or not. (I suspect that getting rid of the shenanigans will
> be a good thing, but let's double-check that...)

Just uploaded a patch to
https://sourceforge.net/tracker/index.php?func=detail&aid=1813597&group_id=12997&atid=112997
Please review.

-Alex

Re: [TCLCORE] Purpose of mmObjType vs pixelObjType

[Alexandre F. <ale...@gm...>]

Hello,

On Mon, Nov 24, 2008 at 2:19 AM, Alexandre Ferrieux
<ale...@gm...> wrote:
>
> Just uploaded a patch to
> https://sourceforge.net/tracker/index.php?func=detail&aid=1813597&group_id=12997&atid=112997
> Please review.

Just to let you know, in the absence of objections, and following
Donal's advice, I committed the patch to HEAD:

	* generic/tkCanvUtil.c	Millimeter patch. Fixes [1813597,2218964]
	* generic/tkInt.h	        by eliminating the functional redundancy
	* generic/tkObj.c       and unnecessary loss of precision of the
	* generic/tkText.c      {pixel,mm}ObjType tandem.

So, millimeters as an objtype can start decaying. Will be gone in 1e31
years, like protons.

Help appreciated for backports.

-Alex

Re: [TCLCORE] Purpose of mmObjType vs pixelObjType

[Alexandre F. <ale...@gm...>]

FWIW, I believe I understand why the round trip through a
fixed-distance unit (here millimeters) was done.
The reason is that a screen distance like "2i" means a different
number of pixels on two windows belonging to screens of different
resolutions.
So it is in theory possible that the cached, pixel-converted value of
this distance be unduly used as is on another screen.

However, once this (extremely improbable) situation has been spotted,
it is fairly trivial to avoid it, by invalidating the internal rep
when a change of pixelPtr->tkwin is detected. That's the purpose of
the just-committed update.

-Alex

>
>        * generic/tkCanvUtil.c  Millimeter patch. Fixes [1813597,2218964]
>        * generic/tkInt.h               by eliminating the functional redundancy
>        * generic/tkObj.c       and unnecessary loss of precision of the
>        * generic/tkText.c      {pixel,mm}ObjType tandem.
>
> So, millimeters as an objtype can start decaying. Will be gone in 1e31
> years, like protons.
>
> Help appreciated for backports.
>
> -Alex
>