About to break everything with a merge
FPS measurement in debugscript, more python analysis
Don't sigfpe as much
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
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.
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.
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.
Add MPFRC++ mpreal type It's slow but less slow than Rationals. Project complete. Haha I wish.
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%
Careful, you may have to shade your eyes Except for all the things that don't quite work, shading works perfectly.
A Song of Floodfills and Segfaults Ok, just need to make the FloodFillOnCPU not stack overflow...