X-Git-Url: https://git.ucc.asn.au/?a=blobdiff_plain;f=irc%2F%23ipdf.log;h=c8238a43c34598195587808225309197805532bf;hb=ec323369c2feb7e163b3f6533cf2fc8d6ecaba56;hp=45b1eae866bc4a8c2c4870ddefde0f1ae0488c04;hpb=8c09e7dd80d75c4972f2f9fc27df1a01ee7229e8;p=ipdf%2Fdocuments.git diff --git a/irc/#ipdf.log b/irc/#ipdf.log index 45b1eae..c8238a4 100644 --- a/irc/#ipdf.log +++ b/irc/#ipdf.log @@ -3275,3 +3275,109 @@ 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 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. :)