[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: RFC: graphite and sub-pixel coordinates
From:       Werner Trobin <wtrobin () mandrakesoft ! com>
Date:       2000-06-08 5:45:13
[Download RAW message or body]

Waldo Bastian wrote:
> 
> On Wed, 07 Jun 2000, Werner Trobin wrote:
> > Hi!
> >
> > At the moment graphite only stores the integer coordinates
> > used by the Qt coordinate system to represent the position
> > of objects.
> > As soon as I'll add zooming and printing support this
> > will surely suck :)
> >
> > I'm thinking about adding rulers and page borders to
> > graphite and about supporting *real* coordinates. At the
> > moment I'm not sure whether to use float, double, or fixed
> > point integers.
> 
> Keith Packard looked into the same issue for providing sub-pixel accurracy
> within X. He recently put a paper about anti-alliassing and such up
> somewhere. (Google is your friend)

Well... mosfet is my friend, too. :)
I remembered that he had a news item about the new X rendering model:
For all pixel-geeks: http://www.xfree86.org/~keithp/talks/render.html
(really worth reading)

> Anyway, you probably don't want to use floats/doubles because the accuracy is
> rather poorly defined (e.g. large numbers are less accurate than small
> numbers) So probably the best choice is to use fixed point math.
> 
> E.g. using 32 bits divided as 24.8, gives you plenty of bits on both sides of
> the dot I would guess.

That's what Keith says, too - I'll go for that solution.

> Btw, floating point math can actually be faster than fixed point math because
> floating point math is typically handled by another part of the
> processor/co-processor, giving more room for parallel execution. You can only
> tell after implementing it and measuring the difference. Probably highly
> depends on the compiler/processor as well.

Yes, mhk said that, too. I'm still sort of DOS/ASM influenced, and some years
ago everyone said: Don't use fp math unless you really have to :)
(/me still has a file with a sinus table around... :P )
Thinking about MMX, 3DNow, AliVec and really powerful streamlined FPUs,
OO-Execution, Parallel Execution,... this point seems to be void (at least
for single precision) more or less :)

Due to the fact that the current "pixel" value will be cached I don't see
any performance hit. The only situation where this has to be recalculated
is a zoom factor change and printing.

-- 
Werner Trobin - wtrobin@mandrakesoft.com

[prev in list] [next in list] [prev in thread] [next in thread]