Re: problem with Raster

[mcmullin]

Hmmm...

Well, following Glen's reminder that he *had* tried
Sven's December patch to ZoomRaster.m, but found
(actually, *I* found!) that it caused attempts at
actually zooming to crash the X server, I have had
another look at this.

Summary: I don't understand it.

Detailed Summary: there are funny things going on deep
in tcl/tk and/or X - and I don't understand them.



However: having carefully re-read Sven's patch, *and* the
tk docs, *and* reviewed the actual behaviour of
programs with and without this patch, I have
tentatively concluded that this patch is mistaken:
Nelson's original code was actually correct. (But, the
tk documentation is quite obscure here, so I could yet
change my mind again!)

My understanding is that we can tell tk to organise the
raster as a "grid", and specifically only allow
resizing in "grid units".  Nelson's code defines a
"grid unit" as the "raw" size used in setWidth:Height:,
and thus allows resizing only in increments of this;
whereas Sven's modification would define a "grid unit" as
whatever a single "virtual point" gets zoomed to. As I
say, on reflection, I think Nelson's was the correct
setting.

BUT: Sven is absolutely correct that, given Nelson's
setting of the "grid", the getHeight and getWidth in
Widget will not work (they return the height/width in
"grid units" which, with Nelson's code, equates to the
zoomfactor - which is *not* what we want!).  On my
view, the solution to this is *not* to alter the "grid"
configuration (which, in itself, works fine), but to
override getHeight and getWidth in ZoomRaster, as
follows:

  -(int) getWidth {
    return (logicalWidth);
  }

  -(int) getHeight {
    return (logicalHeight);
  }


Note that this is *not* the same as my original
suggested fix, even though it looks awfully similar.
My original proposal was to override these methods in
Raster.h, but I now believe this would be wrong.  (It
happened to work in my app, but I think it would fail
in general...).


===============

What I have *not* been able to achieve is a good
diagnosis of exactly what goes wrong when Sven's patch
is put in place.  As far as I have been able to trace,
once the ZoomRaster is extended beyond the next
allowable "increment", the very change in its size
causes *another* configure event on the window
requesting an even greater increase, and that then
snowballs (until you manage to terminate the program,
or the X server crashes!).  This recursion seems to
kick in when expanding between zoom factors 3 and 4.
I've traced the code involved fairly carefully, but it
all seems to disappear into tk and then I can't follow
it anymore.  But since I've convinced myself that
Nelson's code was right in the first place, I'm not
intending to chase this any further.

Cheers,

Barry.



-- 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| Barry McMullin, ALife Group,               |    address@hidden |
| Santa Fe Institute, 1399 Hyde Park Road,   |  Voice: +1-505-984-8800 |
| Santa Fe, NM 87501, USA.                   |  FAX:   +1-505-982-0565 |
| http://www.eeng.dcu.ie/~mcmullin           |                         |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++