X-Git-Url: https://git.ucc.asn.au/?p=ipdf%2Fdocuments.git;a=blobdiff_plain;f=irc%2F%23ipdf.log;h=1649e774ea34cb6d47dd718a351069b5e781cfcd;hp=4802402add99b7e52f6ec8b35ce042efbdbe596a;hb=dc85acc6c84b5e72e5be4e2cc99d4318c97df221;hpb=26e30e94c1ced752478498c786be5a2f32f1af22 diff --git a/irc/#ipdf.log b/irc/#ipdf.log index 4802402..1649e77 100644 --- a/irc/#ipdf.log +++ b/irc/#ipdf.log @@ -3369,3 +3369,126 @@ 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 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!