Add #define to transform Object bounds on the fly
authorSam Moore <[email protected]>
Wed, 24 Sep 2014 06:27:26 +0000 (14:27 +0800)
committerSam Moore <[email protected]>
Wed, 24 Sep 2014 06:27:26 +0000 (14:27 +0800)
commit1d179b93f6a1b2a4fe3823c26fba862c24bc5d6e
treecd325613064fe79c104907c4e6378eb700aad266
parent03cc1b0a0d0705e0b1d92e13fdb18608c7a00272
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.
18 files changed:
src/controlpanel.cpp
src/document.cpp
src/document.h
src/main.cpp
src/main.h
src/objectrenderer.cpp
src/objectrenderer.h
src/paranoidnumber.cpp
src/paranoidnumber.h
src/path.cpp
src/screen.cpp
src/screen.h
src/svg-tests/cat.svg [new file with mode: 0644]
src/svg-tests/cat2.svg [new file with mode: 0644]
src/svg-tests/panda.svg [new file with mode: 0644]
src/tests/realops.cpp
src/view.cpp
src/view.h

UCC git Repository :: git.ucc.asn.au