X-Git-Url: https://git.ucc.asn.au/?p=ipdf%2Fdocuments.git;a=blobdiff_plain;f=irc%2F%23ipdf.log;h=60fd46c9492db5589bef9dcb350e6537746516aa;hp=155e7ec90230f2e974e31383456297fb9bcbb85c;hb=da74d1e7bf022062c34223e1e20fd97599e294dd;hpb=f222bc5b005fffc94038b90e1dda0af14cad5018

diff --git a/irc/#ipdf.log b/irc/#ipdf.log
index 155e7ec..60fd46c 100644
--- a/irc/#ipdf.log
+++ b/irc/#ipdf.log
@@ -3138,3 +3138,868 @@
 10:07 < matches> You removed SDL from contrib
 10:07 < matches> So now it won't compile on the lab machines
 10:07  * matches gets out the laptop then
+--- Day changed Tue Jul 29 2014
+09:59 < matches> I seem to have this bizarre illness
+10:00 < matches> Where half my head feels fine
+10:00 < matches> And the other half feels like I've been trying to read brainfuck
+10:00 < matches> I hope you don't catch it
+10:00 < matches> The side that is sick is the side that was closest to the group hug
+10:00 < matches> Coincidence!?
+10:00 < matches> I think not!
+10:08 < matches> You know how there's this theory about the two halves of the brain being semi independent and sort of subconsciously able to think by themselves
+10:08 < matches> I think the left side of my brain is dead
+10:08 < matches> It's not responding to pings
+10:09 < matches> I think the project working side might be the alive one though, so we shall see if I can actually do something useful
+--- Log closed Tue Jul 29 23:13:08 2014
+--- Log opened Wed Jul 30 12:03:38 2014
+12:03 -!- matches [matches@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
+12:03 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
+12:03 -!- Irssi: Join to #ipdf was synced in 0 secs
+16:28 -!- sulix [sulix@motsugo.ucc.gu.uwa.edu.au] has quit [Ping timeout: 121 seconds]
+17:25 -!- sulix [sulix@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
+--- Day changed Sun Aug 03 2014
+12:43 < matches> So I found my moronic mistake with the virtual FPU and it seems to actually work
+12:44 < matches> I think it's even slower than using Rational<Arbint>
+12:44 < matches> Unless everything's slow because of the QT now
+12:45 < matches> There's an awful lot of "Rendering QT node" debug
+12:46 < matches> No its the VFPU that makes sense
+12:47 < matches> Since every floating point operation now requires writing 18 hex characters over a unix domain socket
+12:47 < matches> Hooray VHDL
+12:48 < matches> (I'm sure if you have $$$$ and like Enterprise(TM) software VHDL is great)
+12:48 < matches> I'll just do some miscellaneous things and hopefully some of them will be useful
+12:48 < matches> Bye
+14:14 < matches> So with the VFPU and doing everything on the GPU we have 2.2 FPS
+14:14 < matches> It seems to be able to cope with rectangles on the CPU
+14:15 < matches> The circle may present some difficulties
+14:16 < matches> It would be have been pretty cool to change the vfpu and see if anything makes it look like intel
+14:16 < matches> But ultimately useless I suppose
+14:37 < sulix> There might be some info in the hardware docs, though they're pretty incomprehensible: https://01.org/linuxgraphics/documentation/2013-intel-core-processor-family
+14:38 < sulix> AMD also have manuals: http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/
+14:38 < sulix> nVidia are sworn to secrecy.
+--- Day changed Tue Aug 05 2014
+12:38 < matches> I'm looking at the atril source
+12:38 < matches> To see if I can compile it without the oppressive 400% max zoom
+12:39 < matches> It is rather intense
+12:39 < matches> I think the zooms are set depending on the language?
+12:41 < matches> There are po files which are definitely not position independent object files
+12:43 < matches> #define ZOOM_MAXIMAL(zoom_levels[n_zoom_levels - 1].level)
+12:43 < matches> The plot thickens!
+12:45 < matches> Heh this is actually sort of making sense
+12:45 < matches> They have a "cut-n-paste/zoom-control" directory
+12:48 < matches> I'm confused as to how the maximum zoom is 6400% and yet my version will only zoom to 400%
+12:48 < matches> But I guess I shall compile it from source and see what actually happens
+12:51 < matches> They also have a script to configure their configure script...
+12:51 < matches> Oh dear xml is involved
+12:53 < matches> There needs to be a way to save the status of configure so you don't have to rerun it from scratch every time you fix an error
+12:56 < matches> Our document viewer may only be able to render beziers and circles
+12:56 < matches> But at least it doesn't have any dependencies!
+12:56 < matches> Well many
+12:56 < matches> I suppose since SDL is in contrib we should put GMP in contrib too
+12:57 < matches> But yes, I don't care about caja plugins dammit I want to zoom on a pdf
+13:00 < matches> "Warning: Comparison between pointer and integer"
+13:00 < matches> Aaaah
+13:00 < matches> It compiles...
+13:01 < matches> But where did it put the binary...
+13:02 < matches> Oh great it expects things to be in /usr
+13:03 < matches> I guess I will run "install-sh" and hope I will still have a usable pdf viewer
+13:07 < matches> There's a LOT of G_ and g_ variables
+13:07 < matches> Actually functions
+13:07 < matches> I think g_ does not mean global in this context
+13:07 < matches> Maybe
+13:11 < matches> So it's not just a matter of ZOOM_MAXIMAL being redefined to ridiculously huge numbers having any effect
+13:11 < matches> I guess they use some other library that has zooming
+13:13 < matches> It somehow detects what the maximum zoom should be based on the document as well
+13:13 < matches> This is just over engineering!
+13:19 < matches> ev_view_can_zoom_in (EvView *view)
+13:19 < matches> return view->scale * ZOOM_IN_FACTOR <= ev_document_model_get_max_scale (view->model);
+13:19 < matches> Let
+13:19  * matches casually makes it return true
+13:19 < matches> Also wtf
+13:19 < matches> They have a "gboolean" type
+13:19 < matches> Is "bool" inferior?
+13:19 < matches> What more do you need than true and false
+13:20 < matches> Is bool used as a variable name for something
+13:20 < matches> sigh
+13:24 < matches> No ok it still won't let me zoom in more
+13:25 < matches> g_return_if_fail in the zoom functions
+13:25 < matches> They don't look important
+13:28 < matches> There are a surprising amount of places with a "if zoom or scale is bigger than the maximum, return"
+13:28 < matches> Like, are three checks really necessary
+13:29 < matches> I think you can set model->sizing_mode to "EV_SIZING_FREE" but I have no idea what that will do
+13:29 < matches> So I'll just continue commenting out anything that looks like it will return early from the zoom process...
+13:30 < sulix> Sounds like a plan!
+13:31 < matches> The use of g_ for function names makes me want to stab someone :P
+13:31 < matches> I assume it's related to gtk or maybe just gnome
+13:32 < matches> Also about half their doubles are "gdouble"
+13:32 < matches> And the other half are "double"
+13:32 < matches> :S
+13:32 < sulix> gtk had their own crazy, let's implement everything from scratch idea.
+13:32 < sulix> They have their own "classes" in C, IIRC.
+13:32 < matches> It's pretty object orientated yes
+13:34 < matches> Ok I seem to now be able to zoom in a *bit* more and then it just stops drawing things
+13:35 < matches> No wait it's just hopelessly slow
+13:37 < matches> It also zooms in on the wrong spot and then draws it and then moves the view back to the mouse and draws again
+13:38 < matches> But yes, it doesn't cope well with zooming at all
+13:38 < matches> I was kind of hoping it would work
+13:39 < matches> Maybe if I use a simpler document
+13:43 < matches> Congratulations anyway
+13:43 < matches> We can zoom further on a circle than atril can
+13:44 < matches> Unfortunately the reasons atril can't zoom are probably not related to precision
+13:44 < matches> Maybe I need to find some "if zoom > thing don't draw anything" and comment those out too
+13:44 < matches> Sigh
+14:07 < matches> It is resistant to my valgrind attempts
+14:07 < matches> It seems to have spawned 9 processes
+14:10 < matches> Oh "atril" is actually a series of hideous bash scripts that load libraries or something
+14:12 < matches> You know
+14:12 < matches> I'm sure if we tried
+14:12 < matches> We could make a less shitty pdf viewer out of our program
+14:29 < matches> Interesting
+14:30 < matches> "ev_document_render" got called 10.6 Billion times
+14:30 < matches> I don't think I changed the view that many times...
+14:32 < matches> Ok, so just working on our own viewer is probably better at this point than working out why atril has a heart attack if you zoom
+14:33 < matches> I'm going to pretend this wasn't a waste of time...
+14:41 < matches> "existing pdf viewers cap the view because otherwise they break due to bugs that aren't actually related to precision"
+15:43 < matches> So I suspect the GPU Bezier rendering is buggy
+15:44 < matches> Or maybe it's a quad tree thing
+15:45 < matches> Or both...
+15:46 < matches> I'm pretty sure the appearance of an individual bezier should not depend on what other beziers are in the document :P
+15:47 < matches> Yeah there's wierd quad tree shit going on
+15:48 < matches> I'm going to try and add some sort of glyph/font like thing
+15:49 < matches> It's either that or create hand drawn beziers in the current view
+15:50 < matches> But I feel it desperately needs an example of being able to actually zoom in and create something at an "arbitrary" level
+18:54 < matches> So we sort of have a very broken, very badly written, SVG parser
+18:55 < matches> A bunch of bugs showed up in the bezier rendering
+18:56 < matches> Although it might just be fglrx
+22:23 < sulix> The GL code is now consistantly broken, rather than sporadically broken.
+22:24 < sulix> Trying to render SVGs with it might count as modern art, though.
+22:39 < sulix> Man, the buggier the bézier code gets, the more beautiful its output.
+22:53 < sulix> Voilà: http://davidgow.net/stuff/ipdf-koch-svg.png
+23:11 < sulix> And on the CPU: http://davidgow.net/stuff/ipdf-koch-svg1.png
+--- Day changed Wed Aug 06 2014
+11:00 < matches> That looks amazing!
+11:04 < matches> I'm sorry
+11:04 < matches> All I seem to do is add bugs :S
+11:05 < matches> And XML
+11:13 < sulix> I suspect you removed a lot of bugs with the -DQUADTREE_REMOVED. :P
+11:14 < matches> It's the bit where parts of my Bezier code have been wrong for more than a month that make me feel guilty :S
+11:14 < sulix> The GPU code was wrong in the same way.
+11:15 < sulix> Also it used to corrupt all of the memory.
+11:23 < matches> So you're not using the koch.svg file?
+11:23 < matches> That breaks for me
+11:23 < matches> Which isn't surprising considering the svg parsing code
+11:24 < sulix> I was using koch1.svg from your Lit Review
+11:25 < matches> Oh right
+11:25 < matches> koch.svg isn't actually a valid svg file :S
+11:26 < sulix> I tried it with a random, complex SVG from the internet, and segfault.
+11:27 < matches> Haha
+11:27 < matches> Yeah it works
+11:27 < matches> We can zoom in further than atril!
+11:28 < sulix> Victory!
+11:34 < matches> So I was trying to think about shading things... and stroke thickness... and all those other things in SVG...
+11:34 < sulix> Yeah, I thought about those.
+11:35 < sulix> I came to the conclusion that I should probably try to make the quadtree work first.
+11:37 < matches> Probably :P
+11:58 < sulix> btw, your computer's clock is slightly out.
+11:58 < sulix> alternatively there is a lot of time travel going on
+11:58 < sulix> (secretly, I'm hoping it's the latter)
+11:59 < sulix> (im my mind, I'm good enough to have bugfixed the SVG code before it was written)
+17:10 < matches> Yeah I removed ntpd because my boot kept stalling at it for several minutes
+17:17 < matches> The GPU Bezier renderer seems a lot more conservative about how many lines it uses
+17:18 < matches> I thought I remembered just copying the GPU algorithm for the CPU but maybe I didn't
+17:20 < matches> Oh
+17:38 < matches> Some of the shader stuff confuses me...
+17:38 < matches> Like: "pixize = vec2(pixel_w/bounds_w, 100*pixel_h/bounds_h)"
+17:39 < matches> Random factor of 100 ?
+17:39 < matches> As far as I can tell pixel_w,pixel_h is always 640,480
+17:57 < matches> Hmm
+17:57 < matches> But the window isn't 640,480
+17:57 < matches> Wait
+17:57 < matches> Is it
+17:58 < matches> Yeah
+17:58 < matches> The screen is 800 x 600
+17:58 < matches> That is only slightly confusing...
+17:58 < matches> Should I change all the 640,480 to 800,600 ...
+17:59 < matches> Or will this break things
+18:01 < matches> We are actually passing the width and height of the viewport around so I figure that should probably be used instead of 640 and 480
+18:02 < matches> Also I suspect we want just a few more lines on the beziers since they often start looking more like trapezoids
+18:04 < matches> But only if they are big to begin with
+18:05 < matches> We can probably also do a "if x1,y1 == x2,y2 just use one line"
+18:06 < matches> Or alternately actually implement lines as distinct from beziers but that's silly :P
+18:06 < matches> If I can work out how to do shading then we won't even need rectangles and circles any more
+18:06 < matches> I should probably focus on precision of things but I sort of want to be able to draw something cool first
+18:15 < matches> Oh damn merge
+19:19 < matches> So a series of curveto commands isn't just a series of individual beziers for each three points
+19:20 < matches> I guess it's time to actually read the SVG spec a bit
+19:20 < matches> Oh maybe they are cubic beziers
+19:21 < matches> I thought they were just quadratic unless you used a special command
+21:08 < matches> The order of your coefficients in the bezier geometry shader seems reversed...
+21:08 < matches> But maybe that's because I reversed it in the CPU first...
+21:08 < matches> I don't know
+21:08 < matches> I will leave it in this order and hope it doesn't break
+21:08 < matches> (I'm making the beziers cubic because it seems like a thing we want)
+21:08 < matches> And is required for SVG paths
+21:27 < matches> Hmm
+21:27 < matches> SVGs also have quadratic beziers and as much as setting (x3,y3) == (x2,y2) *almost* looks the same...
+21:29 < matches> Close enough I guess
+21:30 < matches> I don't particularly want to add seperate objects for quadratic beziers since I've only ever seen cubic ones in SVGs anyway
+21:49 < matches> http://szmoore.net/ipdf/svgshape.png
+21:49 < matches> Woo!
+21:50 < matches> I'm actually pretty excited about having a semi usable svg viewer that can zoom, if not indefinitely, a lot further than any of the open source image viewers will let you zoom :P
+21:51 < matches> Shading... that's hard
+21:51 < matches> Stroke thickness is kind of hard too...
+21:51 < matches> Blergh
+22:22 -!- sulix [sulix@motsugo.ucc.gu.uwa.edu.au] has quit [Ping timeout: 121 seconds]
+23:42 -!- sulix [sulix@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
+--- Day changed Thu Aug 07 2014
+21:24 < sulix> So it turns out ttf fonts were not very difficult to add at all: http://davidgow.net/stuff/ipdf-ttf.png
+21:42 < sulix> And fixed the glyphs.svg rendering: http://davidgow.net/stuff/ipdf-glyphs.png
+22:06 < sulix> So all of those Béziers make Gmpint very slow.
+22:07 < sulix> It also runs out of memory very quickly.
+22:11 < sulix> About 30 second of dragging an svg around uses ~15G of ram.
+22:13 < sulix> It takes (with Rational<Gmpint> CPU rendering) ~10 G to render the default frame of glyphs.svg
+22:18 < sulix> Okay, it just broke a computer w/ 32 GB of ram.
+22:20 < sulix> Code is pushed, btw, for your computer-wreckingly-awesome enjoyment.
+22:32 < sulix> I tried fixing Rational::ToDouble() and using GPU w/ CPU coordinate transform.
+22:32 < sulix> Still runs out of memory.
+22:33 < sulix> But it works, even if it's still a tad slow.
+22:45 < sulix> Okay, memory use is not a problem at all if we delete out GMP integers after we're finished with them.
+22:46 < sulix> (There was a TODO: to that effect)
+--- Day changed Fri Aug 08 2014
+16:11 < matches> Wait you just did the things *I* was supposed to do for this week :P
+16:11 < matches> I hope you don't want me to fix quadtrees...
+16:13 < matches> Ah sorry about the GMP 
+16:14 < sulix> I gave the QuadTrees another go as well, but random half-letter-"b"s were everywhere.
+--- Day changed Mon Aug 11 2014
+10:56 < matches> Ok I think I need to throw all design principles out the window adding a keyboard handler
+10:57 < matches> I know you were keen on having a mouse handler independent of the Screen class
+10:57 < matches> But the Screen class detects the events
+10:57 < matches> It really makes sense for the event handlers to just be member functions
+10:57 < matches> Maybe virtual in the unlikely event that there are ever different types of Screen
+10:58 < matches> Probably the View should handle the events
+10:58 < matches> Then we wouldn't have this convoluted thing where View has a reference to a Screen but Screen has a pointer to a View...
+10:59 < matches> But I need to let that go and actually do useful things
+10:59 < matches> So KeyboardHandler is now a member of Screen
+10:59 < matches> Delicious spaghetti
+11:02 < sulix> I think I can bring myself to forgive you. :)
+--- Day changed Tue Aug 12 2014
+13:48 < matches> I can draw rabbit_simple.svg
+13:48 < matches> !
+13:48 < matches> Almost
+13:50 < matches> IT IS BEAUTIFUL
+13:52 < matches> Wait I think quad trees are enabled
+13:53 < matches> Nope they aren't
+13:53 < matches> Oh wel
+13:54 < matches> http://szmoore.net/ipdf/infinite-precision-document-FOX.png
+13:54 < matches> That didn't take very long
+13:55 < matches> I suspect the wierd bits in the wrong spot are because there are translations applied to things
+13:55 < matches> Because inkscape
+13:57 < matches> Hmm yeah
+13:58 < matches> I wonder why there are random straight lines between things though
+13:58 < matches> They are filled regions of the same colour and no stroke but obviously we just read the beziers and draw the outlines
+14:50 < matches> Dammit SVG
+14:50 < matches> So the y coordinate of text refers to the bottom
+14:50 < matches> The y coordinate of *everything* *else* refers to the top
+14:51 < matches> It's alright this is ipdsvg we aren't constrained by stupid standards
+14:59 < matches> Ergh somehow fonts are broken in eye of mate...
+14:59 < matches> How did I even...
+15:00 < sulix> Fonts are usually handled with y=0 being the "baseline" of characters.
+15:10 < matches> There are a few wierd things going on with straight lines
+15:11 < matches> Hmm only at the default zoom
+15:11 < matches> Horizontal lines on both cpu and gpu are kind of wobbly
+17:23 < matches> Ok I am suffering from an attack of matrix algebra
+17:23 < matches> It was bound to happen sooner or later I guess
+17:24 < matches> The spaghetti is cooking nicely
+17:26 < matches> The fact that our document is all in GL coordinates and SVGs are not is causing me way more confusion than it really should be
+17:27 < matches> All I need to do is set an initial transformation matrix then everything else should Just Work
+17:27 < matches> Of course it does help if you actually use matrices instead of Rect's
+17:29 < matches> Also I think functions that modify arguments passed by references is one of the things that tpg hates
+17:29 < matches> But there are a lot of them here
+17:29 < matches> They are so convenient!
+22:03 < matches> If I can get transforms and groups actually working properly, we can probably hack some sort of recursive thing together and use view reparenting
+22:03 < matches> Somehow
+22:05 < matches> I'm thinking putting the fox in the rabbit's eye and so on recursively would actually be pretty damn awesome
+22:05 < matches> It is easy to say these things though...
+22:06 < sulix> So, I have view reparenting "working" in the quadtree code.
+22:06 < matches> :O
+22:06 < matches> Cool
+22:06 < sulix> (The rest of the quadtree doesn't work, so the point is somewhat moot, though)
+22:06 < matches> Wait you already had that working, but you have rendering bugs
+22:06 < matches> Yeah
+22:06 < matches> :P
+22:08 < sulix> I will push that now, actually.
+--- Day changed Wed Aug 13 2014
+00:34 < matches> Yes
+00:34 < matches> I have defeate
+00:34 < matches> d
+00:34 < matches> Basic matrices
+00:36 < matches> So it is pretty ugly and inefficient but meh
+00:36 < matches> We have translate, scale and matrix
+00:37 < matches> skew will be pretty easy to add but probably useless
+00:37 < matches> rotate is a bit harder
+00:38 < matches> Also the skewing operations obviously don't work on rectangles
+00:38 < matches> Or anything that isn't defined in terms of bezier paths I guess
+00:38 < matches> But translating and scaling will
+00:40 < matches> Ok, so SVG has a "defs" thing that lets you define groups without drawing them
+00:41 < matches> And a "use" thing that lets you insert a group
+00:41 < matches> Actually element in general
+00:41 < matches> Doesn't have to be a group
+00:41 < matches> So
+00:41 < matches> I wonder if doing recursive magic with that works
+00:48 < matches> Not in normal svg viewers it would seem
+00:49 < matches> Hmm
+00:51 < matches> (eom:7883): librsvg-WARNING **: Circular SVG reference noticed, dropping
+00:51 < matches> That's just boring!
+00:52 < matches> So I think we will need some fairly major changes to our Document structure to get much more SVG stuff working
+00:53 < matches> I wonder if we actually need to store a DOM if we want that to work
+00:53 < matches> Also I thought I fixed transformations but they still break for fox-vector.svg :(
+00:58 < matches> I think "broken" will probably be the most commonly occuring word in our git commit messages
+11:05 < matches> Oooh
+11:06 < matches> svg-tests/recursive.svg is slightly recursive viwed in firefox
+16:10 < sulix> The QuadTree works again!
+16:10 < sulix> (I have finally worked out how to multiply by two, it seems...)
+16:11 < sulix> Also s/ again//
+17:23 < matches> Project complete!
+18:05 < sulix> Man, nVidia has an OpenGL extension where you can just pass the "d" attribute of SVG paths in and have it render them for you.
+18:05 < matches> Oh
+18:05 < matches> Welp
+18:07 < sulix> It's like: glPathStringNV(path, GL_PATH_FORMAT_SVG_NV, strlen(d), "M100,180, L40,10, etc...")
+18:08 < matches> Presumably you could just replace 90% of the SVG stuff with that then :S
+18:09 < sulix> It only works on nVidia hardware, though, so it's not really practical.
+18:10 < matches> I think I need to actually do the Bezier's bounding rectangles correctly
+18:10 < sulix> I was just about to add that, actually.
+18:10 < matches> But its not just (x0,y0,x3-x0,y3-y0)
+18:10 < matches> Ok
+18:10 < matches> Go ahead then
+18:10 < sulix> Nah, you have to take the x and y components separately and solve for min and max.
+18:11 < matches> Yes google is a lot faster than actually doing maths
+18:13 < matches> I can add that unless you've already written it?
+18:13 < sulix> Sure.
+18:13 < sulix> The internet seems to claim that you should use newton-raphson to find the roots of the derivatives, but I'm not really comfortable with doing that for cubic béziers,
+18:31 < matches> I just differentiated the parametric formula
+18:31 < matches> And got a quadratic
+18:31 < matches> Unfortunately there is a slight problem with Real
+18:31 < matches> Since we don't have a general "sqrt"
+18:31  * matches adds that to the growing list of "fix later"
+18:32 < matches> It doesn't compile for Rational<Gmpint> anymore anyway
+18:38 < matches> I am writing code that sjy would probably not consider elegant
+18:50 < matches> Well that totally broke everything
+18:53 < sulix> So it turns out that the view reparenting was only working by chance.
+18:55 < matches> :(
+19:20 < matches> Hmm it turns out finding the bounding box of a bezier has really annoying edge cases
+19:43 < sulix> Okay, automatic generation of new quadtree nodes "works" when zooming in.
+19:44 < sulix> It doesn't do any fancy clipping, so the actual rendering code hits precision issues, but it's still pretty cool.
+19:48 < sulix> It also get a bit buggy if you try to pan over the edges of quadtrees, as it only renders one node at a time.
+19:59 < matches> Nice
+21:14 < sulix> I have just achieved infinite precision with the quadtree!
+21:14 < sulix> Only on rectangles, only when zooming in, and only when the camera doesn't cross a quadtree boundary, but it works!
+--- Day changed Thu Aug 14 2014
+09:50 < matches> cool
+10:37 < matches> I'm beginning to suspect whoever said to use the Newton Raphson method to find Bezier bounding boxes was right
+10:43 < matches> I love how the sites I looked up said "Obviously there is a problem if a = 0 or b^2 - 4ac < 0, but we can just make sure we always pick beziers that don't cause those problems
+10:44 < matches> Ok
+10:44 < matches> I have at least got an algorithm that returns finite sized bounding boxes now
+10:45 < matches> I think it even works!
+10:45 < matches> But only on the CPU
+10:45 < matches> Presumably the GPU does something to cope with the fact that the bounding boxes were totally wrong before?
+10:53 < matches> Oh it wasn't doing anything because they were {0,0,1,1}
+10:54 < matches> I have to transform the Bezier coefficients before they are uploaded to the GPU
+10:54 < matches> Blergh
+10:55 < matches> What I've basically done is change it to be the opposite of how it was designed
+10:55 < matches> -_-
+10:56 < matches> So before, the Bezier control points were relative to some bounding rectangle but when I parsed the SVG I just made it always {0,0,1,1} so the coordinates were absolute
+10:56 < matches> Now I have changed the Bezier control points to be absolute and then calculated a bounding rectangle from them
+10:56 < matches> I can maths
+10:57 < matches> So I could make the Beziers still have the {0,0,1,1} bounds which will fix the GPU renderer without having to transform the coefficients
+10:57 < matches> And just leave this "SolveBounds" function in for actually getting the bounds
+10:58 < matches> Except SolveBounds is disgusting
+10:58 < matches> And slow
+10:58 < matches> So I could add a Bounds member variable to the Beziers
+10:58 < matches> And then we have two bounds
+10:58 < matches> I seem to have coded myself into a catch 22 "No matter what you do it is terrible" situation
+10:59 < matches> Adding a Bounds member variable to the Bezier struct sort of defeats the whole point of the "Object of Arrays" idea
+10:59 < matches> You know what
+11:00 < matches> I think the "Object of Arrays" approach has caused more problems than it solved :P
+11:02 < matches> (Probably not actually)
+11:09 < matches> Spaghetti
+11:09 < matches> I'm going to transform the coordinates before uploading to the GPU shaders
+11:09 < matches> Because I think that is the least objectionable?
+11:09 < matches> I don't know
+11:09 < matches> I still don't like any of the solutions
+11:10 < matches> But having more than one bounding rectangle definitely seems dumb
+11:10 < matches> Especially if the other is *always* {0,0,1,1}
+11:11 < matches> I hope this doesn't totally break your quad tree
+11:15 < matches> Actually looking at the quad tree it seems that is the best way to make it more likely to work
+11:21 < matches> I feel like we should use SVGMatrix more and Rect less
+11:21 < matches> But oh well
+11:29 < sulix> Ah: so the Quadtree kinda relies on the Bézier coordinates being relative to the bounding rectangle.
+11:29 < matches> Yep
+11:29 < matches> I'll do that
+11:29 < matches> It's easier to do the transform when the coordinates are uploaded to the GPU
+11:29 < matches> Although probably less efficient
+11:30 < matches> On the other hand, the CPU renderer relies on having absolute coordinates
+11:30 < matches> Two renderers
+11:30 < matches> TWICE the matrices
+11:30 < matches> TWICE the confusion
+11:31 < matches> And Rects are not really convenient because they aren't a proper transformation matrix
+11:31 < matches> I can't just multiply some Rects together
+11:31 < matches> Or calculate an inverse
+11:32 < sulix> Yeah, there are problems there.
+11:34 < matches> Hmm
+11:34 < matches> I *almost* fixed it
+11:34 < sulix> Rects are really good for the QuadTree, though.
+11:34 < matches> We should leave it as rects
+11:34 < matches> You just manually work out what it needs to be anyway
+11:35 < matches> I think the inverse of the equivelant matrix will always work as a rect
+11:35 < matches> So there are random lines missing from the beziers now
+11:35 < matches> But the ones that are there are in the right spot!
+11:36 < matches> (On the GPU)
+11:36 < sulix> So, I looked at that. I see random missing lines on Intel, not on nVidia.
+11:37 < matches> Oh were they missing before?
+11:37 < matches> Well I don't recall them being missing before
+11:37 < matches> Oh
+11:37 < matches> I know what it is
+11:38 < matches> When the bounding rectangle has width or height of zero
+11:38 < matches> Sigh
+11:38 < matches> Wait that can't be it
+11:38 < matches> Most of the missing lines aren't straight horizontal or vertical
+11:38 < matches> :S
+11:39 < sulix> I think it's just dodgy rounding on the GPU.
+11:40 < matches> I will push what I have I guess
+11:40 < matches> I have nice pretty debug rectangles (in *colour*) around the beziers when they are rendered on the CPU
+11:40 < matches> Somehow I don't think that is going to be sufficiently impressive progress in the meeting
+11:41 < sulix> Oooh... I'm looking forward to trying that.
+11:41 < sulix> I have an impressive Quadtree demo to do!
+11:41 < sulix> Assuming the bezier stuff doesn't suddenly break.
+11:41 < matches> ... it might
+11:41 < matches> Ok, I will `git stash` and then `git pull` as opposed to merging
+11:42 < matches> Yes, there are definitely not randomly missing beziers in your code
+11:44 < matches> Wait, was your quad tree working with beziers before?
+11:44 < matches> It wouldn't have been?
+11:44 < matches> All the bounds were wrong
+11:48 < matches> Ooh
+11:48 < matches> H and V
+11:48 < matches> What are they
+11:49 < sulix> Horizontal and Vertical lines
+11:49 < matches> Ah
+11:50 < sulix> The QuadTree works with beziers, but doesn't increase precision.
+11:52 < matches> Hmm, now to work out which of the 5 or 6 edge cases is breaking the Bezier bounds algorithm
+11:53 < matches> It's kind of hard to debug
+11:53 < matches> The edge cases apply seperately to the y and x directions
+11:53 < matches> So you can't tell just by looking at a curve that it is an edge case
+11:54 < matches> Unless you are a mathemagician I guess
+11:55 < matches> I don't understand
+11:55 < matches> The bounds for the beziers that disappear look right
+11:59 < matches> Maybe I'm not uploading the data correctly anymore
+12:03 < matches> Ok now it only breaks for the horizontal and vertical lines which I at least understand
+12:03 < matches> I was iterating over the object bounds and uploading the ones that had a type of BEZIER
+12:03 < matches> Oh
+12:03 < matches> Oh
+12:04 < matches> Yeah because I added a GROUP as well
+12:04 < matches> And every <path> gets a GROUP now
+12:04 < matches> So the order of indexes must be off
+12:14 < matches> Face palm
+12:14 < matches> This is why we have objects.data_indices
+12:19 < matches> I wish I'd added the SVG stuff earlier
+12:19 < matches> It makes it a lot easier to do stuff when you can mess around with actual documents
+12:42 < matches> I have pushed some stuff
+12:43 < matches> Mostly it just looks like I added a bunch of colourful rectangles to the CPU rendering
+12:43 < matches> I think I broke the Quad tree too
+12:43 < matches> Go team
+12:43 < matches> Oh and there are a bunch of not so colourful GPU rectangles
+12:43 < matches> Due to the "GROUP" object just using the outline rectangle shaders
+12:44 < matches> So part of the quad tree seems to work on the GPU but not all of it
+12:44 < matches> And none of it seems to work on the CPU?
+12:48 < matches> Also instead of rendering a slightly broken fox it now renders a segfault
+12:48 < matches> Similarly for the koch snowflake
+12:48 < matches> It's alright we can still draw Humphrey
+12:53 < matches> Oh
+12:53 < matches> It's just the quad tree that segfaults on the more complicated svgs
+13:38 < sulix> I have returned from the committee meeting, and that stupid 2/3rds majority thing has been revoked!
+13:38 < matches> Hooray!
+13:39 < matches> I should head towards University for the project meeting
+13:39 < matches> It is tempting to just stay home
+13:40 < matches> But that would probably not be wise
+13:41 < sulix> You should come.
+13:41 < sulix> I'm going to see if I can fix the Quadtree, but it looks like your changes have thoroughly broken it.
+13:41 < matches> Sorry!
+13:41 < sulix> By which I mean, it probably was only working if everything had bounds (0,0)-(1,1)
+13:41 < matches> Haha
+13:42 < matches> You can just undo my changes to demonstrate it if you want
+13:42 < matches> To the bus
+13:43 < sulix> I may yet do that...
+14:54  * sulix -> CSSE
+19:08 < matches> So shading on the CPU sort of totally breaks
+19:08 < matches> But it exists
+19:08 < matches> Progress!
+19:10 < matches> Bezier bounds are not as good as I'd hoped
+19:10 < matches> I think they only work if the end points form the bounds
+19:17 < sulix> Ah...
+19:21 < sulix> Btw, in the default "c" glyph, there are _two_ curves with bounds (0,0)-(1,1)
+19:21 < sulix> Numbers 9 and 18
+19:22 < matches> Yeah I found the wierd ebounds
+19:22 < matches> It's in the font code
+19:22 < matches> There is an AddBezierData with (0,0,1,1) instead of AddBezier (which automatically works out the bounds)
+19:22 < matches> For vlines
+19:22 < sulix> That'd do it.
+19:23 < matches> shape.svg seems to lose part of the curve now
+19:23 < matches> I've made the bezier control points relative
+19:23 < matches> Things mostly sort of work
+19:23 < matches> But the quad tree still looks fantastically broken
+19:25 < sulix> It always looks broken if you pan around or zoom out: it's my ugly baby.
+19:28 < matches> http://szmoore.net/ipdf/brokenbeziers.png
+19:28 < matches> To be fair the beziers are actually fine
+19:28 < matches> It's just the bounding rectangles that are broken
+19:28 < matches> Also shading should probably not be turned on unless it is actually a closed path
+19:29 < sulix> Hmm...
+19:29 < matches> Wait
+19:29 < matches> The beziers are rendering fine
+19:29 < matches> But the bounding rectangles are wrong
+19:29 < matches> Does this mean
+19:29 < matches> If I *fix* the bounding rectangles
+19:29 < matches> It will break something
+19:29 < matches> :-(
+19:29  * matches forges ahead nevertheless
+19:30 < matches> It does look suspiciously like it is only ever using P0 and P3 for the bounds
+19:30 < matches> Despite all that horrible solving for the turning points
+19:31 < sulix> Yeah.
+19:31 < matches> Oh
+19:32 < matches> I suspect if I fix this it will totally break the absolute to relative bezier transform then
+19:35 < matches> The file for those beziers is kind of interesting
+19:35 < matches> inkscape has used absolute commands for all except one of the beziers
+19:35 < matches> Why?
+19:35 < matches> The first one was copied and pasted with the control points moved
+19:35 < matches> Also for some reason random "translate" applied to the whole group
+19:36 < matches> It might make some sense if it caused the coordinates of the actual paths to come out as integers maybe
+19:36 < matches> But they don't
+19:37 < matches> There is translate and then the initial "moveto" is not 0,0
+19:37 < matches> I guess we shouldn't be trusting an svg editor that segfaults if you try recursion anyway
+19:59 < matches> Ok, high school maths:1, 5th year science/engineering student:0
+20:15 < matches> Also my amazingly clever shading algorithm has
+20:15 < matches> ...
+20:15 < matches> issues
+20:15 < matches> When the paths are not in the view
+20:16 < sulix> Ah...
+20:18 < matches> In fact it has many issues in many cases
+20:27 < matches> Hmm
+20:27 < matches> I wonder if this is what causes problems with evince/atril
+20:27 < matches> Ok not this
+20:28 < matches> I mean, if they use a similarly terrible except actually working shading algorithm
+20:28 < matches> And just draw everything to a really big texture so they can use it
+20:28 < matches> As opposed to clipping things
+20:28 < matches> That seems a little unbelievable though
+20:29 < matches> Surely that would crash long before you even got to >1600%
+20:30 < matches> I suppose what I should really do is look up some papers on shading
+20:30 < matches> Blergh
+20:35 < matches> Things are pushed
+20:37 < matches> Ah crap
+20:38 < matches> Things will be pushed in 8 hours according to my clock
+20:38 < matches> Just don't do anything until after 4am tomorrow and everything will be in the right order
+20:38 < matches> :P
+20:39 < sulix> That shading is _amazing_
+20:40 < matches> Try replacing the colour with rand()%255 for even more amazingness
+20:40 < sulix> If you zoom in _just_ the right amount, all hell breaks loose. I love it!
+20:40 < matches> Haha
+20:40 < sulix> Slowly panning across it is also magical!
+20:41 < matches> Try it on rabbit_simple.svg
+20:42 < sulix> I think Humphrey might have come down with a case of stripey binary myxomatosis.
+20:43 < matches> So I will have to think about shading a bit more :P
+20:43  * sulix braves the unholy combination of shading and quadtree.
+20:43 < matches> Oh I didn't try that
+20:44 < sulix> It actually doesn't look any different.
+20:44 < sulix> I think the quadtree only breaks w/ the GPU.
+20:44 < matches> Yes
+20:45 < matches> You lose the debug message if the node # > 9 it seems too
+20:46 < matches> At least the quad tree works on the CPU
+20:46 < matches> But why doesn't it work on the GPU they are now using the same bounds
+20:47 < matches> So should I prepare a report for Tim?
+20:47 < matches> Progress Report: Arbitrary precision numbers are unsurprisingly, totally infeasible
+20:47 < matches> Therefore, we implemented random bits of SVG
+20:47 < matches> Figure 1: A totally broken shading algorithm
+20:48 < sulix> You should include this image of the quadtree: http://davidgow.net/stuff/ipdf-humphreys-ghost-face.png
+20:48 < matches> Yes
+20:48 < matches> I wonder if since we're allegedly engineers we should document what bugs go with what images
+20:48 < matches> Hmmm
+20:49 < sulix> That's why I name the screenshots like that, I know this goes with the "Humphrey's Ghost Face" bug.
+20:49 < matches> Haha
+20:49 < matches> So we have the svg-test images
+20:50 < matches> Would it be worth while to have a commit script that automatically drew them and did screnshots
+20:50 < matches> It might be tricky though because you have to test panning and zooming and things
+20:50 < sulix> Yeah... perhaps videos?
+20:51 < matches> We'd need to be able to control the view automatically
+20:51 < matches> Which is actually required for that list of things in the proposal we are supposed to do anyway
+20:52 < sulix> I think we'll want that feature at some point anyway for doing proper performance tests
+20:54 < matches> I kind of want some sort of debug overlay for things like the bounding boxes too
+20:54 < sulix> Hmmm... the bounds look right: http://davidgow.net/stuff/ipdf-humphrey-bounds-ahead.png
+20:54 < matches> And a menu system
+20:54 < matches> And the ability to "insert SVG here"
+20:54 < matches> And open a file browser
+20:54 < matches> And...
+20:54 < matches> And...
+20:54 < matches> Yeah
+20:54 < sulix> I've been seriously considering doing a menu system.
+20:54 < matches> Too bad christmas is after the thesis is due
+20:54 < matches> Do it!
+20:55 < matches> We're running out of mouse buttons to toggle things :P
+20:55 < matches> Are there any SDL based menu systems that we can use easily?
+20:55 < sulix> There are a couple of OpenGL-y ones that might work.
+20:56 < matches> Let's not port the project from SDL -> FreeGlut
+20:56 < sulix> No.
+20:56 < sulix> Let's not.
+20:57 < sulix> (I'm looking for an SDL/OpenGL menu system so that I can replace FreeGLUT in the Graphics project(
+20:57 < matches> Could we use Qt or is that overkill?
+20:57 < sulix> I suspect it's probably overkill.
+20:59 < sulix> I've got a couple of old GUI libraries for SDL/OpenGL I wrote in high school I could dig up as a last resort.
+20:59 < matches> ... I have seen your high school code
+20:59 < matches> :P
+20:59 < sulix> (I think one of them uses a tiny bit of boost, though, so I'd rather avoid it)
+21:03 < matches> I kind of want to look at Qt at some point
+21:03 < matches> Maybe if we have the menu in a seperate window...
+21:03 < matches> Then we need threads...
+21:03 < matches> Then we have two problems...
+21:09 < matches> All the links to SDL libraries are broken
+21:34 < sulix> I'm not sure what changed, but now ipdf crashes my OpenGL debugger.
+21:42 < sulix> The QuadTree/GPU code works again!
+21:42 < sulix> Somehow the bug I fixed last night reappeared, but I've added the needed *2s back in.
+--- Day changed Fri Aug 15 2014
+08:43 < matches> So it seems to work well but things still go wierd on the GPU
+08:44 < matches> I'm in Quadtree node 32 looking at the tip of Humphrey's eyebrow
+08:44 < matches> The bottom line moves normally
+08:44 < matches> Vertically only sorry
+08:44 < matches> It doesn't move horizontally
+08:44 < matches> The top line stays still and every so often jumps to a new (wrong) position
+08:45 < matches> On the CPU it appears fine though
+08:45 < matches> Although on the CPU it doesn't show the "Current View QuadTree Node: 32"
+08:46 < matches> Hrm, I should add a 2d view of a car to the svg-tests
+08:47 < matches> Then I can be like "IT IS RELEVANT TO MECHANICAL ENGINEERING BECAUSE BEZIERS"
+08:47 < matches> In the conference/thesis offense
+08:48 < matches> My concern is actually more how I'm going to present the arbitrary precision number representations because they don't even work
+08:49 < matches> Well I should probably try Gmp rationals and Gmp floats before totally giving up I guess
+08:49 < matches> And also those p-adic things
+08:50 < matches> I never looked them up
+--- Day changed Sun Aug 17 2014
+14:38 < matches> Hey Qt has a lot of stuff in it
+14:38 < matches> They have their own iostreams that seem identical to std::iostream
+14:39 < matches> It's kind of cool I guess except there are "Qs" everywhere
+14:41 < matches> Ok we need a window icon
+14:41 < matches> This is vital
+15:54 < sulix> I've got SDL2 window icon setting code if you want it: https://github.com/sulix/omnispeak/blob/master/src/icon.c#L555
+16:04 < matches> Cool
+16:39 < matches> I'm bringing in spaghetti
+16:39 < matches> I mean Qt
+16:40 < matches> In theory this means the Debug functions should have a mutex if we want to debug things in the Qt stuff
+16:40 < matches> But in practice screw it
+16:40 < matches> What could go wrong?
+16:41 < matches> (Don't worry, I have a CONTROLPANEL_DISABLED define)
+16:42 < matches> This View/Document/Screen thing could probably be tidied up a lot
+16:42 < matches> But effort
+16:42 < matches> I think I'll just give ControlPanel direct access to document, screen and view
+16:42 < matches> Currently everything has to go through view
+16:43 < matches> Which would make more sense if some of screen was in view maybe
+16:43 < matches> Bah screw design
+16:51 < matches> So now we have 4 main classes!
+16:51 < matches> 4 x the fun!
+17:29 < matches> Bargh Qt needs its own version of make
+17:29 < matches> That's stupid
+21:09 < matches> So
+21:10 < matches> I have a mysterious LMS deadline that suddenly appeared
+21:10 < matches> "Progres Report"
+21:10 < matches> Description
+21:10 < matches> "asadf"
+21:10 < matches> Due
+21:10 < matches> 19th August, 11:01PM
+21:10 < matches> What
+21:14 < sulix> Oh dear.
+21:15 < matches> I have sent an email
+21:15 < matches> I hope that's not the conference abstract
+21:15 < matches> I also really hope we're allowed to use our own computer and things in the conference
+21:16 < matches> Also I really hope that if I can use my own computer it doesn't decide to shit itself anyway just to spite me
+--- Day changed Mon Aug 18 2014
+17:06 < matches> Good news and bad news!
+17:07 < matches> The kerning now appears to kern in the right direction
+17:07 < matches> But this means "BleedingCowboys.ttf" works
+20:30 < sulix> It's a pain to look up clipping of beziers, because there's a separate technique for doing something else called "bézier clipping"
+20:40 < matches> Baha
+20:41 < matches> I'm basically just procrastinating with Qt
+20:41 < matches> I mean
+20:41 < matches> Doing *awesome* things with Qt
+20:48 < sulix> I am looking with considerable envy at SolveQuadratic().
+20:49 < sulix> SolveCubic() will get very ugly.
+20:49 < sulix> Assuming I don't just sample the cubic at 100 points and look for roots.
+20:49 < matches> Haha
+20:49 < matches> Newton Raphson?
+20:50 < sulix> Very tempting.
+20:50 < matches> Then you can solve any bezier!
+20:50 < matches> Then we can put in Quintics!
+20:50 < sulix> Solving cubics exactly is not fun.
+20:50 < sulix> Dear god no.
+20:50 < matches> Imagine how many loops a quintic could have...
+20:51  * sulix cries quietly in the corner.
+20:53 < matches> So I'm calling AddText with sane values and nothing is happening :(
+20:56 < sulix> With or without quadtree?
+20:56 < sulix> With quadtree, everything is broken if you try adding things.
+20:56 < sulix> Because they won't be added to a node.
+20:57 < matches> No quad trees I think
+20:57 < matches> Yeah no quad tree
+21:00 < matches> Wait I think we need to rebuild the buffers or something
+21:07 < matches> Ah, ForceRenderDirty()
+21:14 < matches> I don't think the scale of our text is quite right?
+21:14 < sulix> Well, the scale of everything is wrong, but it's entirely possible that the text is _extra wrong_
+21:16 < sulix> In theory, the "scale" input to addText is the "height" of a character.
+21:19 < matches> Mmm
+21:19 < matches> I'm trying to add text relative to the current view
+21:19 < matches> But it isn't consistent
+21:19 < matches> When I go to a different view it is definitely not adding it in the same relative place
+21:20 < matches> The scale and positions aren't *already* relative are they?
+21:22 < sulix> Not to the view...
+21:24 < matches> What are they relative to?
+21:24 < matches> Anyway instead of fixing that bug I'm adding more
+21:25 < sulix> Umm... The bounding box maybe?
+21:25  * sulix investigates.
+21:26 < sulix> Scale and position should (I think) be normal, document coordinates.
+21:26 < matches> Odd
+21:26 < matches> Oh well
+21:26 < matches> Having Qt is totally worth it by the way
+21:27 < matches> Although it is still slightly embarrassing that it has its own SVG parser
+21:27 < matches> Ours is better!
+21:27 < matches> It has Reals everywhere!
+21:27 < matches> Except where it constructs Real from floats...
+21:27 < matches> And converts them to floats...
+21:28 < sulix> Thesis title should be "Keepin' it real: Staying afloat on the sea of document precision"
+21:31 < matches> Bahaha
+21:31 < matches> That is brilliant
+21:32 < matches> The Qt stuff is never deleting anything
+21:32 < matches> I suppose I should fix that at some point
+21:33 < matches> So basically it is a state machine and you use the menu to change the state
+21:33 < matches> Pressing OK does something depending on the state
+21:34 < matches> And there is a single text edit you can type stuff into
+21:34 < matches> In theory it can hide/show different widgets depending on the state
+21:34 < matches> I feel like I should add a "Generate Thesis Title" widget now...
+21:35 < matches> Also I can sort of see the appeal of lambdas for GUI programming now
+21:35 < matches> But I have a feeling they would totally break Qt anyway
+21:49 < matches> ...
+21:49 < matches> Ok sometimes the text gets added upside down...
+21:49  * sulix disclaims any and all responsibility for that.
+21:51 < matches> Yes!
+21:51 < matches> I finally did that thing I was saying I'd do for like 3 weeks
+21:51 < matches> Zoom in to floating point limit
+21:51 < matches> Add SVG
+21:51 < matches> Watch it explode!
+21:52 < sulix> Oooh...
+21:52 < matches> It is glorious
+21:54 < matches> We need to be a bit careful with thread safety in qt
+21:55 < matches> Really we should be able to request that the qt thread call UpdateAll itself
+21:55 < matches> Rather than calling it directly from the viewer thread
+21:55 < matches> But I'm not sure how that's done
+21:55 < matches> There's all this stuff about "Cross thread signals" on the internet
+21:56 < matches> It seems you can hide/show things but not much else
+22:47 < matches> Bah you pushed things!
+22:55  * sulix proclaims the new features as excellent and promptly goes to bed.
+--- Day changed Tue Aug 19 2014
+18:08 < matches> My conference is in the week starting 13th October
+18:08 < matches> Is Tim back then?
+18:08 < matches> "your supervisor will be invited to attend and mark your presentation"
+18:09 < matches> So if he can't go... I don't get a mark?
+18:12 < matches> It sounds suspiciously like they are going to get everyone's supervisors to mark them and then just scale everyone :S
+18:13 < matches> Surely at least one other person is going to read the final report...
+18:13 < matches> I've heard bad things about the engineering scaling system
+18:14 < matches> Your mark becomes inversely proportional to how well your supervisor's students did the previous year or something like that
+18:15 < matches> Anyway, two months left to accomplish something!
+20:05 < sulix> Worked out why the font bounds were weird.
+20:06 < sulix> AddText takes (msg, scale, x, y) not (msg, x, y, scale), so the coordinates were all bunk.
+20:09 < sulix> Fonts looks _amazing_ with floating pt errors, too.
+20:09 < sulix> http://davidgow.net/stuff/ipdf-i-think-you-mean-comic-fail.png
+20:29 < sulix> The Art of Computer Programming briefly mentions the Stern-Brocot tree, btw.
+20:29 < sulix> I can't see it being really useful, though.
+21:06 < sulix> My difficulty clipping bézier paths may be because it is actually impossible.
+21:06 < sulix> I think I've just found a paper saying that it is only possible for béziers which happen to be straight lines.
+22:55 < sulix> Never mind, it is possible, it's just very nasty.
+23:15 < sulix> Also C++14, because we need more lambdas: https://isocpp.org/blog/2014/08/we-have-cpp14
+--- Day changed Wed Aug 20 2014
+12:05 < matches> I guess we've accomplished the goals for this week's meeting then!
+12:05 < matches> (That shading algorithm totally counts as a "first attempt")
+12:07 < sulix> I'm about 2/3rds of the way through deriving the reparametrisation of béziers.
+12:08 < sulix> It basically just boils down to pages and pages of rearranging polynomials.
+12:38 < sulix> I managed to get the qt4/qt5 monstrosity compiling on my laptop.
+12:38 < sulix> It has a "moc-qt4" program, which works, whereas "moc" is qt5.
+16:28 < matches> I think I need to stop adding this log to git...
+23:08 < sulix> matches: But then, how would history record that I've finally got a maybe-correct derivation for cubic bézier reparametrisation: http://davidgow.net/stuff/cubic_bezier_reparam.pdf
+23:08 < sulix> (Code is in git)
+--- Day changed Thu Aug 21 2014
+12:57 < sulix> So it turns out that quadtrees are hard, and reparametrising béziers is why.
+13:03 < matches> I don't seem to see anything anymore with the quad tree enabled
+13:10 < sulix> The quadtree doesn't let you add things in realtime.
+13:10 < sulix> Quadtree nodes are immutable once created.
+13:12 < matches> Ah
+13:35 < sulix> debug: ReParametrise (bezier.h:190) - (0.000000,0.000000),(1.000000,1.000000),(1.000000,1.000000),(1.000000,1.000000) -> (-nan,-nan),(-nan,-nan),(-nan,-nan),(-nan,-nan)
+13:36 < sulix> Looking good!
+13:54 < sulix> Clearly, the quadtree rendering is now perfect: http://davidgow.net/stuff/ipdf-this-is-definitely-a-fox.png
+--- Day changed Sun Aug 24 2014
+17:51 < matches> ...
+17:51 < matches> I am parsing CSS in the SVGs
+17:51 < matches> WHAT HAVE I DONE
+17:52 < matches> Blame inkscape for always using css to control the properties
+17:57 < matches> http://szmoore.net/ipdf/death-by-shading.png
+17:59 < matches> Anyway there is a proper "Group" data type like with the Beziers
+18:00 < matches> So if you want to cache things related to groups you can put them in that I guess
+18:02 < matches> Really it should be called "PATH" not "GROUP" but I vaguely thought it might be able to be used as either
+--- Day changed Mon Aug 25 2014
+10:39 < matches> I was thinking about how to do shading more
+10:40 < matches> And I basically arrived at the idea Loop and Blinn have that you kept talking about
+10:40 < matches> Except I didn't realise it at first because my version was all using rectangles instead of triangles
+10:40 < matches> I think I will try to get my scanline fill to work first though
+13:03 < matches> It sort of works
+13:15 < matches> ... or not
+--- Day changed Tue Aug 26 2014
+14:25 < matches> I wonder if I'm going to end up just reverse engineering an algorithm that I was too lazy to understand properly
+14:26 < matches> I really like the idea of flood fill better than doing insane triangulation maths
+14:26 < matches> Surely GPUs can flood fill
+14:28 < sulix> I think they can, but either very slowly or only on very new hardware...
+14:28 < sulix> I think you'd need to do it in several passes, maybe?
+14:28 < matches> The problem I had with flood fill was working out where to start
+14:28 < matches> I have something that almost works
+14:28 < matches> That requires no clever maths...
+14:29 < matches> But it is CPU only
+14:29 < matches> And probably breaks in a bunch of special cases
+14:30 < matches> It doesn't have precision problems though (once you've drawn the boundary that is)
+14:31 < matches> It would still be cool to go through the Loop/Blinn algorithm on CPU and GPU
+14:31 < matches> Because that is going to have floating point maths in it
+14:31 < matches> flood fill has no floats
+14:31 < matches> Therefore it is infinite precision
+14:31 < matches> Objective complete
+14:32 < matches> Actually I don't think my algorithm is proper flood fill, it's sort of scanline flood fill but not?
+14:32 < matches> When in doubt write random code
+14:34 < sulix> How are you handling the case where, due to a path being half offscreen it becomes two paths?
+14:34 < matches> ... I am not
+14:35 < matches> If part of the path is offscreen it is annoying
+14:36 < sulix> Hopefully, once some of the quadtree code is more functional, the path clipping code can be used to clip paths to the screen.
+14:39 < matches> Compositing is also totally broken because the fill just looks for black pixels
+14:40 < matches> But if I can get it doing fonts then that's sort of not totally useless
+18:35 < matches> I am very tempted to implement a "Please click on the location to fill this path from" interface at the moment
+18:39 < matches> Alright, I have shading somewhat stack overflowing
+18:39 < matches> I mean
+18:39 < matches> Working
+18:39 < matches> *
+18:39 < matches> ********
+18:49 < matches> http://szmoore.net/ipdf/shading-the-only-svg-that-doesnt-segfault.png
+20:43 < matches> Argh
+20:43  * matches stabs coordinate transforms
+20:43 < matches> stab stab stab
+20:44 < matches> My filling algorithm is to find the 4 extrema of the path
+20:44 < matches> And try and flood fill inwards from each one
+20:45 < matches> But the extrema pixel coordinates keep transforming to *outside* of the path
+20:45 < matches> By one pixel
+20:45  * matches stabs
+21:52 < matches> I guess I should just actually implement loop and blinn shading
+21:52 < matches> Flood fill is not as easy as I had hoped
+21:53 < matches> I have to start doing annoying geometry maths to work out what point I can start the flood fill at
+21:55 < matches> Sigh
+--- Day changed Wed Aug 27 2014
+22:33 < sulix> Suddenly: ToAbsolute on ToRelative does not give original Bezier
+22:34 < sulix> I may need to rethink what my quadtree code is doing to those poor curves.
+22:51 < sulix> Never mind, that assertion happens _whenever_ trying to load cubicbeziers.svg.
+23:03 < sulix> Oh wow: you should see what happens if you start splitting and reparametrising beziers with bad precision.
+23:03 < sulix> 'tis "whacked"
+23:08 < sulix> http://davidgow.net/stuff/ipdf-a-slight-curve.png
+23:15 < sulix> And the Quadtree infinite precision for béziers now works*
+23:15 < sulix> *for some beziers.
+23:15 < sulix> * for some large finite value of "infinite"