Define for Transformations on Path only, also fixed segfault due to GraphicsBuffer The "invalidated" is used to recycle memory in the GraphicsBuffer, but that can only be done if there is actually enough memory. This was causing a segfault if the document was initially empty and had things added to it. Can now remove the hack in main.cpp where documents started with a {0,0,0,0} RECT in them. We can now (ab)use the Path for transformations. The idea was that Arbitrary precision stuff might be faster if we only care about the bounds of the paths. Unfortunately the way Real was used everywhere will make it a bit difficult to actually use this. We need Beziers and their bounds to be stored with floats, but the Path bounds to be stored with GMPrat or some other arbitrary type. It probably won't help that much, but evaluating those Beziers with GMPrat really slows down the CPU renderer. It's also a giant hack because I still use BezierRenderer for GPU rendering but I now use PathRenderer for CPU rendering of Beziers. Le sigh. We can now store Bezier bounds relative to Path bounds and apply transformations only to the Path bounds.
Add #define to transform Object bounds on the fly View model: Object bounds are fixed, transforming view transforms the View bounds, Object bounds transformed to coordinates in View bounds before rendering. Mutable Objects model (?) : Object bounds are transformed by operations, no transformation to View bounds necessary The equivelant view bounds are still printed for comparison, but it is effectively (0,0,1,1) First approach requires one transformation when altering view and then a *lot* during rendering Second approach requires a lot of transformations when altering view and then <not as many> during rendering Second approach also means we don't need a dedicated CPU renderer. Coordinates within bounds can be expressed as floats. ALSO - Added cat and panda test images - Fixed segfault due to empty paths in cat.svg ... by not including empty paths... - ipdf will now run if the window can't be created so I can run it on the bus without X - Not much you can actually do without X though... - ParanoidNumbers got considerably more #defines for debugging and trying to make them less generally shit - Fixed some bugs in PN not revealed by realops tester - There are still bugs in PN that aren't revealed by anything - Despite it basically being exactly equivelant to doubles at the moment :S - Having bugs in basic mathematics operations is actually really really really hard to fix - Want to fix all the bugs so I can make PN faster - They are slow, they spend about 30% of their time doing std::vector stuff - And that's when the std::vector is *empty* ALSO - The new approach to rendering means that the loss of precision is nowhere near as bad - This means we need to make new tests to demonstrate that there is in fact still a point to using arbitrary precision - Because floats are actually quite amazingly good if you aren't a moron about how you apply operations. - Really panicking now ALSO - I'm sure I did something else but I forgot what it was.
All of the things and none of the sleep GMPrat is a type that works (un)surprisingly well, until you start changing the view. ParanoidNumbers explode more dramatically but actually simplify for certain things. Simplify seems to end up adding operations that don't cancel twice, eg: debug: TestRandomisedOps (tests/paranoidtester.cpp:152) - Test 1000*1 randomised ops (max digits = 4) ERROR: TestRandomisedOps (tests/paranoidtester.cpp:208) - {7+(7/10)} *= {119} ERROR: TestRandomisedOps (tests/paranoidtester.cpp:209) - {7*119+(99127/10)} ERROR: TestRandomisedOps (tests/paranoidtester.cpp:210) - double Yields: 916.2999773025512695312500000000000000000000 ERROR: TestRandomisedOps (tests/paranoidtester.cpp:211) - PN Yields: 10745.7001953125000000000000000000000000000000 FATAL: int)() (tests/paranoidtester.cpp:212) - Failed on case 102 Note 7*119 * 119 = 99127, so the *119 is being applied extra times Probably because of reasons that hopefully the cold light of morning will reveal.
Change to things to make performance testing easier - Saving of CPU and GPU BMPs - OverlayBMP doesn't overlay a BMP which is good because we don't want it to... - SVG loads in centre of view - This will break the Quad tree, probably - tests/bmpdiff allows us to quantitatively compare output bmp images. - I didn't say it was a good metric, there's just a metric now. - Arguments to set rendering and transform type, argument to set maximum number of frames to render, argument to turn off the lazy rendering. Will make some kind of ipython notebook next I guess.
Slightly better results Assuming we can trust Wolfram's Giant Ego, err, I mean Wolfram Alpha, to give exact results, it is generally giving a better result than doubles. Try simplifying the "a/b + c/d" cases next? Also at the moment "(a + b)*c" does not simplify to "a*c + b*c" even if a*c is exact. Have to be careful because sometimes making the representation more exact ends up making the conversion back to double have a bigger error.
Break maths some more CombineTerms is somewhat horribly broken But it works well enough to beat doubles at "0.3 + 0.3 + 0.3" ... And nothing else I've tried. In fact it's worse or equal to doubles at everything else so far. But I haven't done many operations because CombineTerms breaks everything. Maybe it will get better if that isn't broken horribly.
Make it work on Cabellera (again) I keep forgetting I shouldn't use C++11 features THEY ARE JUST SO CONVENIENT! :( Clownfish has C++11 but the open source AMD drivers don't like geometry shaders and sulix threatened me with dire consequences of installing fglrx... Also fix the symlinks in svg-tests
Now with GNU MultiPrecision (GMP) integers gmpint.h is (in theory) mostly inline and shouldn't add much overhead and was simpler than trying to understand the C++ "binding". The Str() function is kind of terrible but that can't be helped. Also fixed bug in realops tester (even the testers have bugs...) And removed asm tester because the asm function is gone. The bezier testers now don't compile, I don't think we need them anymore.
Arbint subtraction/addition deal with borrow/carry correctly, maybe Eventually they will be right. This still doesn't fix the wierd bezier bug or the growing digits really fast (exponential?). I suspect the former is related to pow(Rational<Arbint>, Rational<Arbint>) and the latter probably makes sense if you do the theory (considering how fast Rational<int64_t> overflowed).