scaling issue question

[Bernhard Herzog]

On 13.08.2009, Didrik Pinte wrote:
> Does anyone know why the max_scale computation in Thuban/UI/view.py was
> restricted this way ?
>
>         # The window coordinates used when drawing the shapes must fit
>         # into 16bit signed integers.
>         max_len = max(pwidth, pheight)
>         if max_len:
>             max_scale = 32767.0 / max_len
[...]
> Where comes the limitation on 16 bit from ?

That limitation comes from the X protocol where coordinates are expressed in 
signed 16 bit integers.  Without a zoom limitation you can get artifacts due 
to wrap-around of the coordinates.  When the zoom limit was introduces it was 
the easiest way to avoid those problems.

> You can test it easily by loading the iceland sample session and zooming
> in. You are stuck at a 3km scale. Setting the max_scale to a value of
> 32767 allow you to zoom in nearly indefinetily without errors.

Some toolkits try to work around the 16bit limitation (iirc gtk started to do 
this at some point). Maybe modern wxWidgets versions do so too.  Also, maybe 
the dataset simply doesn't show the problem.

Also, X clients that do not use the X drawing primitives, but do all rendering 
on the client side or use the X rendering extension, or use OpenGL for 
rendering don't have to worry about it either.  Not sure what the best 
approach would be for Thuban.  We'd have to keep portability in mind, 
obviously.

   Bernhard

-- 
Bernhard Herzog  |  ++49-541-335 08 30  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20090813/d31e3e86/attachment.bin