Don't try to unmap buffers which aren't mapped.

Fixes the GL_INAVLID_OPERATION that snuck in: this would occur
when calling GraphicsBuffer::Resize() on an unmapped, non-invalidated buffer.

Perpetrate SVG on the codebase

Well, parts of it.
We can have black and white SVG only.
I think it's currently buggy.

I figure we should probably be able to actually parse a document format.
And SVG, despite being XML, seems like the least terrible.

Using pugixml for XML parsing and horrible string tokenising because
SVG is not really a DOM language because of the "d" attribute (-_-)

Did I mention it was the least terrible?

Also, there seem to be lots and lots of bugs with things,
including Quadtree rendering of Beziers and actually just  GPU rendering of more than one
Bezier in general.

Also I compiled atril without zoom limits but it crashes
due to things not related to precision. So we're beating atril I guess. Woo!

CS Lab machines have met their nemesis

The ongoing adventures of overcomplicated makefile land.

David is dictating this commit message by the way,

PS:
 They are i686 and only g++0x from before 0x

Tune in next week for another exciting episode (or installment, you, the
viewer, decide!) of randomly ifdefing things out! Will our heroes
successfully defeat the 32 bit long? Or will they perish in an integer
overflow?

(I think the project is beginning to affect our minds)

Apparently things were done

Remove terrible "pow()" functions

There are many reasons why that was terrible and it finally all came apart
in a segfaultastic display.

We now have Power which only works for integer powers
But we only need those at the moment anyway.

VFPU derpage fixed

In my defence, hex and binary are only 14 digits apart

Add VFPU::Float (but it is broken)

Fails every single realops test.
Also it's stuck at 32 bits still.

Use "Real" in CPU renderer for filled circles

Get it compiling on Cabellera (g++0x not c++11)

... But at what cost?

More QuadTree code.

Fix some quadtree rendering bugs.

Quadtree Rendering for CPU transorm+render

QuadTree Rendering with GPU coord transform.

We should compile even if REAL is not 5

Actually add the Quadtree coordinate code

Quadtree transforms

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

Quadtrees! (Almost)

Change Rational<Arbint> -> Rational<Gmpint>

Works better (not surprising). Can change back @real.h:52

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.

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

Zooming is now sligtly less slow.

C++11 lambdas - are they really worth it?

Divide some numbers by 5.

Fix GPU rendering a bit. Will probably break >1 ob

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

We both fixed bugs.

Clear the carry/borrow flag before add/sub

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).

Arbint subtraction should work* now

Yes I was being clever and resizing if sub.m_digits.size() > this->m_digits.size()
But I forgot about when this->m_digits.size() > sub.m_digits.size()

Passes tests/realops.test now!

On the other hand, CPU rendering of Beziers doesn't work anymore.
I think it's just drawing two lines instead of lots of them.

More debugging, harder realops test

Maybe this is more correct. realops likes it.

digit_t is now unsigned, asm division for 1 digit

We now do the "two's complement" in SubBasic by hand. It is maybe even
correct.

Rational<Arbint> now passes realops.test

Arbint now does sign in division correctly

The tester still sometimes picks up a fith Rational<Arbint> /= operation though.

More testing particularly of negatives

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

Dammit I forgot to `git stash; git pull; git stash apply`

Improved "realops" tester

And there are signs of serious problems in Arbint too!

Slightly less memory errors

Using more std::vector and less memcpy/memset etc.
Still seems to have issues but not segfaulting as much.

Fixed m_sign missing in = operator

Fix a warning/compile error.

Horribly unreliable Arbint's and Rational<Arbint>'s

Changes from before: Arbint's use a division algorithm based on bitshifting.

So, you might get a random segfault (if you scroll you will definitely get a random segfault)
and pretty much every single operation with Rational<Arbints> gives you an accuracy warning...

And yet somehow I can render a Bezier. Really slowly.

Some initial QuadTree goodness.

Render object range on the CPU

Render part of a document (incorrectly) on the GPU

In order to get QuadTrees working, we're going to need to
render small "parts" of a document individually. The way this works
is that, when calling RenderObjectsOnGPU, we now pass a range of
object IDs. The ObjectRenderer will then find (in O(N) time, sadly)
the range of indices needed for that object type and then render those.

Béziers, and other objects which rely on the ObjectID on the GPU being
correct might be broken by this (in some cases), though if so it shouldn't
be too hard to fix by passing an offset in as a uniform.

now with fewer midnight-isms

This might help: divide an arbint by a uint64

Add assembly sources to git

Division less buggy, still slow

Ok I need to put more thought into this. Or just look it up.

It compiles... and runs with FPS of zero

Well I suppose this shouldn't have been totally unexpected...

Arbint class implemented

Seems to not explode, at least, when it only has one digit...

Inner step of multiplication in x64 assembly

Just does the multiplication of the array by one digit, taking into account overflows.
I hope. It's kind of difficult to test.

What I need is a VM with equivelant instruction set but magically uses decimals instead of binary 64 bit, so I can test with numbers
that my feeble human brain understands directly...

Arbint class with += and -= operators

Using x64 assembly routines for addition and subtraction loops,
but C++ for memory management through std::vector

Dealing with the sign is a bit annoying.

(Get it?)

Use the lea instruction to reduce number of "inc"s

More moronic bugs

So that P/-Q simplifies to -P/Q, -P/-Q simplifies to P/Q, properly this time

Arbitrary integer addition in x64 assembly

Who needs portability?

Also yes I could probably just use a library but that seems like cheating.

Maybe don't use all of the lines. Or maybe do.

The CPU version. CPU rendering still looks slightly different to GPU.
Replicates behaviour in 54798ed9050d0742c6cdab067fad0cc364b1d6b2

Also actually use the right +/- operators for Rational.
Oh and compile as rational by default because we like things to explode right?

Moronic bug identified, also Backtrace is a thing now

Copy/Paste bug @rational.h:123

At least division and addition both involve maths right?

Rational representation

Buggy, partly due to integer overflows, partly due to moronic bugs that have yet to be determined.

Maybe don't use all of the lines. Or maybe do.

Fix the missing bit of GPU béziers.

Off by one!

Béziers on the GPU.

So this was a terrible thing in many ways.

What we're doing:
- Converting all of the coefficients to floats (+ doing a bit of
  preprocessing) and uploading the the GPU.
- Uploading the data_indices array from the document to the GPU.
- Using the vertex ids in the IBO when rendering béziers to get
  the object id, then looking up the data_indices array (as a texture)
  to find which bézier coefficients to use, then reading the bézier
  coefficients from another buffer texture and finally having the
  geometry shader generate 100 lines much as the CPU one does.

We're using buffer textures to access these things because they don't
have fixed sizes (and can get big), so we can't use uniform buffers and
because shader storage buffer objects need OpenGL 4.3, which only graphics
cards manufactured in the last 45 seconds actually support.

The Béziers are quadratic not cubic...

I can maths

Béziers

It's hard to type the ́e so I will just call them Beziers from now.

New struct represents a cubic bezier, can be evaluated. The Objects struct contains a vector of beziers, and a vector of indices for each object.
If an ObjectType is BEZIER than the index can be used to look up the bezier control points. Control points are relative to the bounding rectangle;
so we can reuse the same curves (eg: For fonts).

Rendering happens on CPU only, sub divide and use Bresenham lines.
Bresenham lines are not quite optimal but I eventually gave up.

So we don't have a "line" type, but you can make one by creating a Bezier where x1,y1 == x0,y0
They look kind of wobbly.

Save/Load not tested. It might break. But it will have to be pretty heavily rewritten soon anyway.

Performance graphs!

Amazeballs

Python script for plotting data using Gnuplot

Bugfixes for CPU rendering

Fix segfault caused by RectOutlineRenderer not properly checking bounds on pixel array.
Fix positioning of RectOutline sides in other locations when they were off the screen.

When you zoom in too far, an integer overflow will occur and the CPU rendered objects disappear.
This occured at widths of about 1e-7 (for our test pattern). Improved for now by int -> int64_t

Later need to replace everything except the actual array access with Real's I think. Then make Real's arbitrary precision. Done.

There is a slight size difference between CPU rendered and GPU rendered objects; not sure what the source of this is. Blame rounding.

GPU sometimes leaves off the corner pixels of the rectangles by the way.

Fix RenderPixels, CPU rendering "works"

Implemented CPU rendering for current ObjectTypes

RECT_FILLED (easy), RECT_OUTLINE (ok I need to maths), CIRCLE_FILLED (oh my god how do I maths)

Screen::RenderPixels is FITH but can see the correct(ish) output in "cpu_rendering_last_frame.bmp"

TODO:
 - Fix Screen::RenderPixels
 - Fix reading a BMP from the screen (so we can do "gpu_rendering_last_frame.bmp" as well)
 - Put Beziers in
 - Implement infinite precision document format
 - Profit

Refactor Rendering of Objects (prepare for CPU rendering)

New abstract class ObjectRenderer and derived classes for each type of Object.
It's a bit more complex but hopefully easier to build on now.

There are probably a heap of bugs in this, but I can see the test pattern again, so I'll commit before it gets worse.

Note: We now have to make sure Screen is initialised first or the segfaults will hit the fan.
(Now it makes sense why all those things weren't in constructors in the first place :S)

It also now segfaults if you get View and Screen the wrong way round.

The magic RenderPixels function.

GLSL Shaders -> Files (instead of #define)

So we can edit them without going insane.

Work around a bug in the Intel driver

Looks like we found a new bug in the intel driver!
https://bugs.freedesktop.org/show_bug.cgi?id=79685

Circles (ellipses) have been added (filled only)

Minor perf improvement on nVidia

nVidia's driver does not like you mapping a STATIC buffer, as they're
usually in parts of VRAM not directly accessible by the CPU. The driver
therefore has to migrate the buffer somewhere slower.

We initialize the object bounds buffer by mapping it and writing directly
into it. This is good where we're doing coordinate transform on the CPU:
we're changing it every frame and it can be a dynamic buffer, but we only
need to do it once if the GPU is doing coordinate transforms so we make it a
static buffer.

This change "fakes" mapping a STATIC buffer for the first time by allocating
some CPU-side memory, having the application write into that, and then initializing
the buffer with that. This removes a performance warning on nVidia when switching
to GPU-side coordinate transforms.

Fix an intel LG warning by orphaning text memory

No more pointer arithmetic in GL/use geom shaders

Maybe make some GL code easier to understand

Updated upstream stb_truetype with warning fix

Fix all of the warnings, re-enable -Werror, etc.

Fix the Floating Point

Pun intended

I had two bugs that cancelled each other out and made a self consistent float that was wrong except for all the ones I compared it to!

David helped fix it.

Tests: MakeBitmap -> PointsToBitmap in its own header

To use in other testers.

Tester for Beziers

After a brief* exciting time in which I thought Beziers looked strange at big enough scales, they don't.

Not much progress on the Lit Review front...

Test from one of Kahan's articles

"Why is Floating-Point Computation so Hard to Debug when it Goes Wrong?"

This is a MUCH better example than massive rounding errors as in calculatepi.test

Tester from some lecture notes by Kahan

Supposedly this is a benchmark for determining the worst accuracy of a CPU using roots to a quadratic
I think something wierd is going on; a result of infinity means there is no rounding errors but I'm not sure what results of -nan mean
and that's what I get.

The article is referenced as kahan1996ieee754 in the literature notes

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

Forgot to run `git pull` earlier.
No conflicts.

Tester for loading document in XML format

Inspired by the fact that SVG and HTML are XML and I was trying to write about them in the Literature Notes.

The pugixml library for C++ seems actually usable.
Could do a number of fancy things using it, but really should get back to that Literature Review :S

Add pugixml-1.4 to contrib

pugixml is a "lightweight" XML parser implemented in C++

Add GPU performance queries.

OpenGL 3.1 core profile support.

If you thought the graphics code was ugly before, wait until you try this!

Test representations of floats working*

The boat is floating for now, we just need to make sure it doesn't sink.

BitsToReal and BitsFromReal are consistent with each other...

*Actually looking at the results, for <5,10> vs IEEE half precision... something is wrong
 The plot still looks float-ish though.

Yeah it's broken

Change float representations to be more IEEE-ish

Implemented BitsToReal WRONGLY for like 6 hours.
It's probably still wrong. It works for 8 bit (2,5) floats but probably only because I got lucky.

I am a bit shit at bit shifting.

Tester for exploring the mapping of a float to a real

To visualise the mapping and how you get the trade off between precision and range.

Use low precision, custom, float representations.
Convert via memcpy(3) and copious bit shifting to a Real

Even though Real is actually also a float (default double) at the moment, it's good enough to treat as being an exact representation
when the custom float is 8 bits. Besides, gnuplot can only plot within double precision anyway.

I say "custom" because I have an explicit sign bit for the exponent, which itself is unsigned.
I *think* standard representations have the exponent be a signed int so the sign bit is implied.
Not sure why the mantissa is treated as being unsigned with an explicit sign bit but the exponent isn't?

HFPA says the exponent is between e_min and e_max which is a bit confusing. Is e_min != -e_max normally?

Will do some plots and experiment a bit after sleep.

Tester based on Handbook of Floating-Point Arithmetic 1.1

See also ipdf/documents

Hideously useless buffer perf optimization.

Fix Makefile

The $(BIN) target needed to include the dependencies for header files included via main.cpp

Horrible debug font bufferification. (Sorry)

Don't re-render the display if nothing has changed

We now render to an offscreen buffer, and blit that
to the screen. This probably breaks the bitmap stuff, and I'll
fix that soon.

Slightly less broken GraphicsBuffer implementation.

I copied the original out of some terrible code I'd
written ages ago. It now is less overtly broken.

I'd still like to do an optimized version with Persistant
Mapped Buffers and manual memory control, but that can wait
until post-shaderification.

Real that uses Fast2Sum for addition

I have a feeling this isn't going to improve things at all.

Ability to define Real as long double

`make DEF=-DREAL=2` to compile using long double as Real

Also changed calculatepi to include long double.
And also, only actually integrate using Real if it is something other than float, double, long double.