My eyes, they burn! Also runs faster, slightly less buggy.
Some code cleanup, quadtree fixes, non-quadtree build fixes.
Bugfixes, performance fixes, tears.
Not working Quadtree object adding. But working better than it did before. Assuming you like turtles_all_the_way_down.script to infinite loop when going back up.
Added a profiler, which outputs time taken and calls to various functions. Disable by defining PROFILER_SILENT You can add a zone with PROFILE_SCOPE(name); (which will profile until the scope is exited) or with g_profiler.BeginZone(name); and g_profiler.EndZone();
Fix debugscript, some quadtree stuff and don't intersect vertical/horz lines when useless.
Mostly features added to DebugScript Also got MPFR C++ reals to work Should allow for a quantitative comparison between Rationals and Arbitrary Precision Floats Just... overwhelming amounts of results that it would be nice to get, so I don't know where to start...
Merge branch 'master' of git.ucc.asn.au:ipdf/code
Quadtree addition to root node now functions (w/out Qt) Apologies, etc.
Invalid array indices are not cool
Add objects without quadtree Even when disabled the quadtree manages to break things
Painfully merge branch 'master' of git.ucc.asn.au:ipdf/code Conflicts: src/document.cpp
Adding things to quadtree is implemented but segfaulty. (i.e. it segfaults all of the time, and even if it didn't, it'd crash if you zoomed in, and also you can still only add things to node 0 and really this breaks a lot more than it fixes) For the prosecution, segfaults except: - When run in valgrind - When run in gdb on nvidia hardware Infinite loops when: - You zoom in, zoom out, add an object, and zoom in again.
Add MinGW Win32 Cross Compiling Not tested with Qt4 yet, but works with QUADTREE_DISABLED Build procedure: 1. Put source for GMP and SDL2 in ipdf/code/contrib/ Do 2. and 3. for both 2. Run `./configure --host=i686-w64-mingw32 --prefix="ipdf/code/contrib/win32"` 3. `make; make install` 4. In ipdf/code/src, run `make ARCH=win32 CONTROLPANEL=disabled` 5. Download SDL2.dll for the binary Will try and get Qt4 support in the morning I guess. I am doing this because I want it to be easy for marker(s) to run the software. So I will make a precompiled ipdf.exe for windows in addition to the linux binary. Tested under wine, seems to work. ALSO Why the hell is there a goto in document.cpp
Improve adding things to quadtree (still broken, though)
Totally FITH everything I'm trying to get it so that Path and View can use a different number representation to Bezier. It's not going well.
Merge branch 'master' of git.ucc.asn.au:ipdf/code Conflicts: src/bezier.cpp src/view.h
Critics are panning the quadtree's panning. (It's broken)
Use Gmprat for Path bounds with TRANSFORM_BEZIERS_TO_PATH So, the bounds of Paths are stored with Gmprat The Bezier's are all stored relative to the Path, as floats The transformations are only applied to the Path Gmprat bounds. This seems to work rather well. In other news, the DeCasteljau algorithm in the CPU renderer had no upper limit, which is why it was slowing down so much. The CPU renderer tends to suffer from SIGFPE-itis when using floats, because when you do a cast there is a SIGFPE if the resultant type can't represent the operand. This occurs in a few places that don't actually affect the rendering...
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.