Coordinate transformatioins [Was: Release of gui libraries]

[Willem Rein Oudshoorn]

Nicola Pero <n.pero@mi.flashnet.it> writes:

> > Ok, I this bug is most probably caused by the fact that the 
> > height is rounded up from 187.942856 --> 188.
> > The following patch will always round the size of the 
> > rectangle down.
> 
> No - this patch is not correct - I'm sorry we don't have a
> regression testsuite, but this patch would reintroduce many subtle
> bugs in drawing which I thought I had fixed forever ... garbage
> appearing on multiple resizing of windows etc ... bugs which were
> fixed precisely by fixing the code to floor the extreme points of
> each rectangle, and compute the size as the result.

Well, I know it is tricky.  Why did you think I added the disclaimer ;-)
Seriously.  I did expect that there was a reason for the way it
was implemented.  However, I could find nothing about this
in the ChangeLog (or I did not look good enough).  
Also the way it is now is also not perfect, in some circumstances
it crashes applications :-(.   

> 
> We need to map geometrical figures from the abstract space into the
> device space.  So we need a function mapping each point in the
> abstract space to a point in the device space.  Hm, you make the
> fundamental assumption here that geometrical figures consists of
> points and that the mapping of the geometrical figures is defined in
> terms of the mapping of its points.

In display postscript this assumption is false.  All kind
of modifications are done to achieve acceptable results on
low resolution displays.

>  I suppose if the
> origin of the window lies on a non-integer coordinate, you might want to
> make a difference choice, but I never investigated seriously this issue,
> since we always put windows at integer coordinates.

Well, but rectangles are not always put on integer coordinates.  
This is important with bitmaps.  But bitmaps should have an 
integer size so it does not really matter.

[Derivation of the set of non-decreasing functions from R --> Z
satisfying f(0) = 0 and  f(x + 1) = f(x) + 1 skipped]

> ...  It's a pity we don't have a regression test, so I might not
> remember how to reproduce all the bugs we used to have - but we
> can't go back that way.

Yes, it would be much better if there was a set of regression tests.

> the reasoning behind the way we round coordinates - might help you (or
> whoever else) in the task of fixing (in the right way) coordinate
> roundings in the image compositing (and any other coordinate roundings we
> might need to do), if you want to do that.

Well, it is not something I look forward to, but if xgps crashes
I would like to fix this.  Actaully, I hope that someone can send
me a step by step scenario for reproducing the crash.
(I do not like to guess)

> I'm very happy that you are working on this area, and please don't
> consider this as a 'stopper' for your work in this area ...

No, I actually expected that the patch was not correct.  However 
the feedback that it stops the crash and improves the image displaying
performance is helpful in pinpointing the original bug. 

Also, your explanation is very much appreciated.  Although
I would have proved your mapping lemma differently (I always
have the impression that when the sup property is used there
should be a cleaner proof :-)).


Wim Oudshoorn.