scaling issue question

[Didrik Pinte]

On Thu, 2009-08-13 at 12:13 +0200, Bernhard Herzog wrote:
> 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.

I think I see the problem when the zoom is something around 10m. It
starts to draw a lot of lines in "random" position.

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

Sure. 

Wouldn't it be interesting to split the problem in two ? 

First, there is a user experience that make thuban looks buggy. You zoom
and it does not. So we should solve it and it is quiet simple.

Second, there is this artifacts problem at high scale. IMHO I would try
to let the graphical toolkit manage it. I have to admit that looking at
the code, I do not clearly see how we could prevent drawings that create
artifacts. We could simply add a check to have all the (x,y) being int16
values (wxproj.cpp and baserenderer.py would the only point to check).

What do you think ?

Didrik 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://www.intevation.de/pipermail/thuban-devel/attachments/20090813/da7de1b1/attachment.bin