From 7ae25945f06d6b0eb9f21701210060433db6e49f Mon Sep 17 00:00:00 2001 From: C R Onjob Date: Thu, 7 Aug 2014 01:00:02 +0800 Subject: [PATCH] Automatic commit of irc logs Q: How many lawyers does it take to change a light bulb? A: One. Only it's his light bulb when he's done. --- irc/#ipdf.log | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) diff --git a/irc/#ipdf.log b/irc/#ipdf.log index 45b1eae..0bd8547 100644 --- a/irc/#ipdf.log +++ b/irc/#ipdf.log @@ -3275,3 +3275,78 @@ 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 -- 2.20.1