Okay, really more generally what we need to do is replace e.g. NRRectL and NRRectS with a single type ... maybe NRIRect.
That was the general effect of changing NRShort and NRLong to the same width anyway, since the structures don't differ at all except in the precision they use.
-mental
On Wed, 2003-12-31 at 19:07, MenTaLguY wrote:
Okay, really more generally what we need to do is replace e.g. NRRectL and NRRectS with a single type ... maybe NRIRect.
That was the general effect of changing NRShort and NRLong to the same width anyway, since the structures don't differ at all except in the precision they use.
Okay, what I've done in HEAD is removed the various NR*S types and changed their usages to the 32-bit-precision NR*L types.
I've also introduced NR::Coord and NR::ICoord, which are now used throughout our libnr for coordinate/matrix arithmetic.
(Nathan, if you feel the name is ugly, feel free to change it)
This should also have the effect of fixing zoom again.
To Bulia's credit, his experiment did at least demonstrate that it was safe to do this.
-mental
MenTaLguY wrote:
Okay, what I've done in HEAD is removed the various NR*S types and changed their usages to the 32-bit-precision NR*L types.
I've also introduced NR::Coord and NR::ICoord, which are now used throughout our libnr for coordinate/matrix arithmetic.
(Nathan, if you feel the name is ugly, feel free to change it)
This should also have the effect of fixing zoom again.
To Bulia's credit, his experiment did at least demonstrate that it was safe to do this.
-mental
So, are we done, or do I need to go through cvs history and verify the changes to the files in /src that call libnr?
If we do need those types defined again, I would put the definitions in nr-types.h. Actually, C++ style, wouln't the NR header properly be NR.h?
However, I do not see a reason to keep different precisions of integers. Wouldn't just defining an NR integer to be a long (whatever the machine) in all cases be sufficient? It looks like the changes in the patch, and the stuff you guys are talking about, merely imply giving the data more precision.
I think that now that we are in C++, and are in the midst of cleaning up and reorganizing code, a good way to enforce a proper parameter might be to make the parameters C++ NR::-defined, not C typedefs. So, instead of NRLong, Inkscape::NR::Integer.
Actually, according to the Rearchitecturing Translation Map (what a title), it will be Cairo eventually, anyway.
Bob
On Fri, 2004-01-02 at 10:50, Bob Jamison wrote:
So, are we done, or do I need to go through cvs history and verify the changes to the files in /src that call libnr?
There weren't many such changes; I'm pretty certain the ones I did make are correct.
If we do need those types defined again, I would put the definitions in nr-types.h. Actually, C++ style, wouln't the NR header properly be NR.h?
Maybe, but we'll be doing this incrementally.
I'm not sure what libnr's future is, exactly -- if and when we adopt Cairo for the rendering backend, most of it will go away.
Until then, I want to stick with incremental changes to it, and leave it in the top-level NR:: namespace.
However, I do not see a reason to keep different precisions of integers. Wouldn't just defining an NR integer to be a long (whatever the machine) in all cases be sufficient? It looks like the changes in the patch, and the stuff you guys are talking about, merely imply giving the data more precision.
I did converge on a single integer precision (32 bits for now) -- hence the NR::ICoord typedef.
I think that now that we are in C++, and are in the midst of cleaning up and reorganizing code, a good way to enforce a proper parameter might be to make the parameters C++ NR::-defined, not C typedefs. So, instead of NRLong, Inkscape::NR::Integer.
Well, I'm hoping to get rid of NRLong/NRShort/NRWhatever alltogether.
NR::ICoord is basically the Inkscape::NR::Integer you propose, though it is (deliberately) less general-purpose. I think types should have specific types and associated meanings.
NRLong/NRShort/etc were really just (useless) replacements for the existing gint32/int_32/etc...
Actually, according to the Rearchitecturing Translation Map (what a title), it will be Cairo eventually, anyway.
Right. In the meantime, I'm a little reluctant to make heavy changes to libnr, since we depend on it so heavily none of us completely understand it yet.
-mental
participants (2)
-
Bob Jamison -
MenTaLguY