Automatic commit of irc logs
[ipdf/documents.git] / irc / #ipdf.log
index 45b1eae..c8238a4 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 [[email protected]] has quit [Ping timeout: 121 seconds]
+23:42 -!- sulix [[email protected]] 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. :)

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