Automatic commit of irc logs
authorC R Onjob <matches@ucc.asn.au>
Wed, 6 Aug 2014 17:00:02 +0000 (01:00 +0800)
committerSam Moore <matches@ucc.asn.au>
Wed, 6 Aug 2014 17:00:02 +0000 (01:00 +0800)
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

index 45b1eae..0bd8547 100644 (file)
 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

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