Don't sigfpe as much

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

Merge branch 'master' of git.ucc.asn.au:ipdf/code

Improve adding things to quadtree (still broken, though)

More turtles

Also we can't take logarithms of negative numbers, dur

Compile with float/double again.

Merge branch 'master' of git.ucc.asn.au:ipdf/code

Panning for gold, with the Quadtree!

Sulix celebrates the panning in the quadtree finally working*
with the worst pun yet!

* The segfault doesn't count.

Turtles all the way down

Also fix up DebugScript's performance data
I can actually plot things!

Still haven't actually plotted things, but in theory I can.

Gmprat logarithms now O(1) not O(N)

... Where the "1" is determined log(3), don't get too excited

So we can finally actually print values outside DBL_MIN->DBL_MAX
Now to go through and remove all the cast to doubles...

Keeping it Real, add Gmprat::Str, Gmprat::Log10

Fixed* all those horrible compile errors.
View can now use VReal and Path can now use PReal
and at the moment they are Gmprat unless the quadtree is enabled.

For Gmprat::Log10 there are problems.

Using: log(a/b) = log(a) - log(b)
       log(a*b) = log(a) + log(b)

Unfortunately mpz_div_ui quickly becomes a massive performance issue.
Even when well within the range of IEEE singles.

Need to rewrite Gmprat::Log10 but may as well commit since it works* slowly at least.

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.

More debugscript things, sanity fading fast

Script should still work after loadsvg is used

This is why I always use "<= 0" not "== 0"...
Although if loops were unsigned that still wouldn't help.

Add loadsvg script command, fix ParanoidNumber size limiting*

Need to write some scripts and performance test them now I guess?
Maybe add commands for scripts to output information for plotting.

Lazy + CPU/GPU rendering toggle in script.

Initial support for scripting actions.

Merge branch 'master' of git.ucc.asn.au:ipdf/code

Some quadtree stuff: bugfix + mutation

Doomed to failure

BLasdfuywetraefrdg

Allow for negative Paranoid Numbers

Specifically, when constructed off a string I wasn't checking for a leading '-' sign.
That's kind of important.

Also 'e' notations will probably have to be included at some point.

I am really bad at this...

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.

Commit before breaking everything

Trying to make ParanoidNumber less shit.
Spends a lot of time in std::vector

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.

Make it run on motsugo

Motsugo has a fake X11 server, which allegedly supports OpenGL extensions.
But it doesn't quite work and things tend to segfault.

It works for CPU rendering though.

Animation of precision_vs_zoom

Some sort of vague ipython analysis

Should probably be split into .py files and just use ipython to do the plots.
Should probably see if we can get Jenkins to run things... oh what am I saying.

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.

Merge branch 'master' of git.ucc.asn.au:/ipdf/code

sulix fixed the quad trees and I forgot about `git stash` again.

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.

ParanoidNumbers work except for the simplifying bit...

I really really hope they work anyway.
Tester doesn't fail too disastrously, but PN gives a worse result than doubles.

Add quadtree back to the Makefile

Nope.avi

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.

Paranoia is setting in

Paranoid Numbers are hard to simplify properly. But they work. Kind of...

Heinous Quadtree crimes.

"The bézier tiptoed out of bed. What an adventure it would be to go beyond the
quadtree node in which it had lived its entire life. Its mother had told it
sternly that it was dangerous to wander the dark  wastes beyond the root node.
Bobby Bézier had never believed the stories, though: there were no such things
as wild NaNs that ate all of the coefficients of naughty boys. Bobby looked up
at the sky: the infinite void of night penetrated only by the debug text high
above. Tentatively, he inched one of his endpoints over the quadtree node
boundary. But alas: his mother had perhaps been right all along. She would scald
him so... how would he hide the fact that his endpoint had been clipped right
off!"

Merge branch 'master' of git.ucc.asn.au:ipdf/code

Because merging is going to be fun.

Some really horrible utility Quadtree functions.

Who writes a recursive function with four switch statements in it?
(Apparently, I do...)

The QuadTree is ~72% more amazing.

Add MPFRC++ mpreal type

It's slow but less slow than Rationals.

Project complete.

Haha I wish.

Fix compiling with non doubles

Added really terrible number representation as a series of operations on floats.
It currently gets a few things wrong...

// there is no elegance here. only sleep deprivation and regret.

Basically, clipping Béziers now actually works, because De Casteljau is
no longer totally back to front. (In fact, I think I just made it more back to front,
which cancelled the original out?)

Also disabled zoom out in the quadtree and some dodgy disabled debug in the bezier shader.

Compositing on CPU sort of kind of works if we ignore Alpha*

*Alpha is hard and I'm just going to ignore it.

Hacky fix to "overflood" problem where the fill point is outside the boundary;
since it can't be more than 1 pixel outside, check the neighbours before starting
the fill.

Unfortunately this means if the fill point is only one pixel *inside* the boundary,
there is no fill.

Tried brute force approach for low resolution paths, but that doesn't really work.
Path::PointInside doesn't seem to succeed where it should...

Other things might have happened.

Not much happened towards actually getting infinite precision,
starting to run out of time, panic mode engaged...

PANIC MODE ENGAGED

PANIC LEVELS AT 100%

EMERGENCY ANTIPROCRASTINATION MEASURES FAILED

PANIC LEVELS AT 200%

ENGAGE SHUT UP AND FIX EVERYTHING MODE

FAILED TO SHUT UP

PANIC LEVELS AT 300%

ENGAGE DINNER TIME

DINNER TIME SUCCESSFUL

PANIC LEVELS STILL AT 300%
apathy levels at 1000%

Classify Beziers, use DeCasteljau for CPU renderer

I don't know how glDrawLines does it, but I can't get rid of the wiggles in straight lines done using CPU renderer.
So I switched to DeCasteljau.

Then I made it classify the lines and only use one Bresenham instead of 100 anyway.

Careful, you may have to shade your eyes

Except for all the things that don't quite work, shading works perfectly.

Mostly working, optimize curves completely within nodes.

Slighlymoreworkingish

Crash instead of generating NaN. This breaks everything.

Infinite Quadtree precision now works with some Béziers

You can zoom in a long way on some, others exhibit precision problems after
quite a long way. Probably the curve cannot be further simplified or something?

Add a vec2 struct.

A Song of Floodfills and Segfaults

Ok, just need to make the FloodFillOnCPU not stack overflow...

Merge branch 'master' of git.ucc.asn.au:ipdf/code

Conflicts:
src/document.cpp

Shading still doesn't work

Actually it's supposed to be "filling" shading implies the colour changes.
Whatever.

Some half-done quadtree experiments.

Support colours in shading

Shading doesn't actually work still but that's of minor concern

Béziers magically work with the QuadTree (sometimes)

Also maybe broke qt. It fixed it for my laptop.`

More broken quadtree monstrosity.

Totally break Quadtree Béziers.

Added a Bezier::ReParametrise() function.

This returns a bezier equivalent to the segment from t0 -> t1 of the
original bezier.

Derivation at: http://davidgow.net/stuff/cubic_bezier_reparam.pdf
for now. If it's not too embarrasing, it might end up in the documents repo.

Fix adding text.

(And remove some Debug printing)

Merge branch 'master' of git.ucc.asn.au:/ipdf/code

Noooo

Go nuts with Qt

We can do all the things I promised!*
And we can do it without having to implement a vim style stdio based interface!
Or adding 16 extra mouse buttons!

Qt can parse XML or even SVG all by itself though...
I'm going to ignore that and just keep treating it as a menu system.

* Commit --amend

Well, the set of things we can do is neither a subset nor a superset of the things I promised.

Fix kerning for the first pair of characters

Terrible hacky SolveCubic.

(I'm sorry, but I'm going to need more sleep before I tackle
complex numbers here)

Slightly better kerning maybe?

Make Qt4 work

Needed to generate a special "moc" cpp file from the header file

Inflict Qt4 upon the codebase

I'm getting issues compiling it though
Qt seems to expect some magical auto-generated Makefile

Remove the not-very-functional control panel with a "CONTROLPANEL_DISABLED" define.

Make project relevant to Mechatronics

Also fix missing actually setting the origin with the "moveto" path command.

Don't write past the end of a GPU mem buffer.

(It causes crashiness)

Re-fix QuadTree GPU rendering, discard groups

Attempt Shading + Bezier Bounds (hopefully) correct

Turns out I can't do high school calculus despite 4 years of Physics study.

The shading algorithm I envisioned has several rather hilarious
things wrong with it...

Although that 'j' does look damn good if you set the zoom *just* right...

Make bezier control point coordinates relative

So the quad tree should just have to care about bounding rectangles.
Also so the GPU renderer now doesn't need transforming but CPU renderer does now.

AddBezier assumes absolute coordinates and transforms to relative coordinates
AddBezierData is assuming relative coordinates.

Totally clear.

PS: Basically whatever is convenient/efficient for the GPU is inconvenient/inefficient for the CPU
and vice versa. Fun!

Fix ymax in GROUP bounding box

svg-tests/circlepath.svg has the right box now

BTW: Segfaults in previous commit occur only for quadtree enabled

SVG tests are 100% less symlinky

That's the good news.
The bad news is that somewhere along the way a bunch of them became 100% more segfaulty.

Groups are a thing and sort of have a bounding box now

That was what I forgot in the last commit; I added "GROUP".

So, the idea is that GROUP can be used to shade a path.
Maybe. Eventually.

Or, it could just be used to make quad tree magic easier (?)

Or it could do both! (Since you can pretty easily just turn off the shading...
 but we're getting ahead of ourselves a bit there)

Or, if it gets given a name, then it can be used to implement the <use> SVG tag.
And then we can allow recursion (which regular SVG doesn't support).

Wouldn't it be nice...

Bezier bounds rectangles are calculated correctly

CPU rendering and SVG parsing uses absolute coordinates.
GPU rendering uses relative coordinates (relative to the bounding box).

The Objects struct stores the absolute bounding boxes now.

Previously it was just using {0,0,1,1} (and thus the GPU's relative coordinates were
equivelant to the CPU's absolute coordinates).

I might have fixed some other things but I can't remember.

Support some more SVG stuff.

Can now get a dodgy, slightly hacked bit of gnuplot output to
render.

Clipping for RECT types. Breaks a little.

When using QuadTrees, RECT_OUTLINE and RECT_FILLED are clipped to
the quadtree node.

This lets you zoom in forever on rectangles with a couple of caveats:
1. This is technically wrong for RECT_OUTLINE, as more lines will be added.
2. There are a couple of issues related to the fact that only one node is
   visible at a time. Notably:
   (a) You lose the infinite precision when stradling a quadtree boundary,
       which will happen eventually.
   (b) Zooming out will show random broken things.

However, if you look at shape.svg, you can see how moving the camera around when
both the RECT and the BEZIER are in view, the RECT moves smoothly and the BEZIER
doesn't.

Use correct font metrics from truetype files.

Kerning, etc. should now be correct, but we use a monospace font
so it doesn't matter.

Automatically generate quadtree children.

This mostly works, and does the view reparenting. It doesn't do any clipping,
so we still hit precision issues as (for example) bézier control points are
outside the quadtree node's coordinate system, and become very, very large.

There are some issues with the boundaries of quadtree nodes, as the system
currently can't display two nodes at once. To compensate, it traverses up the
tree until it finds a single node which contains both, though this will be
a distant anscestor if the nodes are distantly related.

Quadtrees are still disabled by default. There are also a couple of minor
changes to the GL code to make it spit out fewer error messages and run
slightly faster on some hardware.

I am an idiot: the quadtree code is now fixed.

tl;dr: needed more * by 2.

iab;wtd*: The index buffers on the GPU contain _two_ elements per object,
one for the top left of the object's bounding box, one for the bottom-right.
We were taking that into account when computing the number of indices to give
the DrawElements() call, but not when calculating the offset into the buffer.

Oops.

*: I am bored; want tedious detail

A bunch of OpenGL debug annotations.

(Which will probably break compiling on cabellera)

SVG transforms now less broken

They work for rabbit_simple.svg now; that's pretty cool
Still appear slightly broken for more complicated SVGs (eg: the fox in ipdf/sam).

svg-tests/recursive.svg produces this error in eye of mate:
(eom:7883): librsvg-WARNING **: Circular SVG reference noticed, dropping

(If you have only one group referencing itself, there is no error but no recursion).

Merge branch 'master' of git.ucc.asn.au:ipdf/code

Still-broken quadtree shenanigans!

Quadtrees are, therefore, still disabled by default.

Only slightly totally broken SVG transformations

Argh

The matrices are ((a c e) (b d f) (0 0 1))

*Not* ((a b c) (d e f) (0 0 1))

I guess it's better than the Rect bounds crap.
But still broken.

SVG text and line elements

Totally not done properly but whatever

Make adding text to the document easier

tl;dr Use Document::AddText() to put text in places
Pass the font file in the Document constructor or call Document::SetFont() to change fonts

ts;iwtrm I am not freeing the font data buffer because I strongly suspect we will want to keep it.

You might be able to have arbitrary precision text only documents really easily if you
just re-add the glyphs at a new scale. That might be better than reparenting each individual bezier.

We could add a Document::Finalize() to free memory like the font data
which is used in creating the document but not needed afterwards.

But I want to be able to interactively add text anyway, so there doesn't seem
to be much point at the moment.

Deal with groups in SVG parsing

ParseSVGNode will recursively parse <svg>, <g> and <group> nodes.

Basically just going to try and implement a bunch more of SVG now.

The "transform" attribute would be a useful one to deal with because svg editors (at least, inkscape)
seem to be rather liberal in using it.

I hope the timestamp for this is correct, I ran git commit --amend but
I don't know if that will fix it.

Merge branch 'master' of git://git.ucc.asn.au/ipdf/code

Yes, we do need to delete m_op somehow.

"fixed" Rational::ToDouble().

Previously if the numerator or denominator was > the range of a double,
Rational.ToDouble() would return NaN. We now check for this case, and
discard precision accordingly.

Fix compiling with Arbint/Gmpint rationals