X-Git-Url: https://git.ucc.asn.au/?p=ipdf%2Fdocuments.git;a=blobdiff_plain;f=irc%2F%23ipdf.log;h=c9da7a6f7724d5458ce991e3d99f25af0f7d6d2d;hp=3a9cbd279aeda49159fae94646b6e9a328165c3d;hb=c30d17efa0ae8ddbb6ec714b2db90dc3ddb135c9;hpb=4a64734f03a9805c1c83612e394344fa632cd334

diff --git a/irc/#ipdf.log b/irc/#ipdf.log
index 3a9cbd2..c9da7a6 100644
--- a/irc/#ipdf.log
+++ b/irc/#ipdf.log
@@ -2946,3 +2946,510 @@
 17:22 < matches> I like that they seem to store the sign as part of the size
 17:22 < matches> If something has a negative size it is negative and has |size| digits
 17:34 < matches> I guess I will try and write some sort of report about how we implemented Arbitrary Integers but they are terrible compared to existing implementations :P
+--- Day changed Thu Jul 24 2014
+14:44 < matches> So I was going to work on the project but existential dread
+14:45 < matches> About whether my major exists
+14:45 < matches> Do I exist?
+14:49 <@sulix> Are you thinking? Because cogito ergo sum.
+14:50 < matches> I'm not sure I was thinking when I picked this major...
+14:50 <@sulix> I did some project code yesterday and then a bug I thought I'd fixed reappeared so I got distracted failing to fix that.
+14:50 < matches> Haha
+14:53 < matches> Should I upset everyone and recommend freshers for wheel again...
+14:54 <@sulix> I'm all for it, but I think the consensus was that we need to make them actually do wheel-y projects first.
+14:55 < matches> That seems kind of hypocritical though
+14:55 < matches> Because nearly none of active wheel has actually done wheel-y projects
+14:55 < matches> Certainly not before getting on wheel
+14:56 <@sulix> My current random guess is that the problem is that people used to fix the desktops and stuff, and now everyone has their own laptops to break.
+14:56 < matches> But I'll be quiet or people might decide I need to be removed due to lack of doing useful things
+14:56 < matches> Yeah
+14:56 < matches> That too
+14:57 <@sulix> I'll definitely bring it up at the meeting.
+15:02 <@sulix> So which CoderDojo forms do I need to fill out?
+15:02 < matches> Ooh!
+15:02 < matches> http://coderdojowa.org.au/volunteer
+15:02 < matches> This one
+15:03 < matches> But now you've said that I'm already adding you to the mailing list...
+15:04 < matches> There's a thing on Saturday in 2.01 in CS at 12:00pm
+15:04 < matches> I hope people actually show up because we are pretty short on presenters
+15:04 <@sulix> Yeah, I've got a programming competition then. I'm trying to work out how much of the schedule for the competitions exists.
+15:06 <@sulix> Okay, apparently there are programming competitions every saturday in August, which will be fun.
+15:07 <@sulix> Although half of them are "details TBD," which sounds ominous.
+15:07 <@sulix> Also there is a round 2 and a round 4 but no round 3.
+15:11 <@sulix> Okay: it looks like the only weeks I don't have programming competitions on are the last 3 on the form.
+15:13 <@sulix> Also I suspect they're running out of names for the programming competitions, because this Saturday's is called the "South Pacific Winter Programming Carnival".
+15:21 < matches> Haha
+15:27 <@sulix> Form submitted. Sorry for the snarkiness.
+15:40 < matches> Brilliant
+15:40 < matches> You can do a C or C++ workshop or something :P
+15:40 < matches> Or just talk about Commander Keen that'll work
+15:40 < matches> Or "Why Javascript is awful and you should forget all the lessons"
+15:42 <@sulix> "Intro to DOS programming." :P
+18:38 < matches> I did a sort of half hearted attempt at writing more about Arbints
+18:39 < matches> Maybe I'll try put fonts in
+18:39 < matches> That seems vaguely like not what I am supposed to be doing right now :P
+18:43 < matches> There's that virtual FPU sitting there doing nothing
+18:43 < matches> That I promised to do things with in my lit review
+18:43 < matches> That Tim is marking
+18:43 < matches> When I haven't actually done anything with it and he knows it...
+18:44 < matches> I can't help but feel like we need a more impressive thing to zoom in on
+18:44 < matches> Or even a way to draw things once we have zoomed in
+18:46 < matches> Does "We implemented Arbitrary Precision Integers but GMP did it better" count as research?
+19:13 < matches> Do we have a memory leak?
+19:13 < matches> I've been running it for a while and things are slowing down
+19:25 <@sulix> matches: With GMP or just doubles?
+19:27 <@sulix> My quick check has us not leaking memory with doubles.
+19:27 <@sulix> Well, X leaks memory and the nVidia driver leaks memory, but we're fine.
+19:35 < matches> I was actually running with singles :S
+19:35 < matches> See push to documents repo
+19:35 < matches> There is a pdf
+19:35 < matches> I did a thing
+19:38 < matches> I'm basing the assumption that x86-64 is IEEE compliant on the fact that it passed the "paranoia" program
+19:39 <@sulix> Yeah, x86_64 is IEEE compliant.
+19:39 <@sulix> x86_32 is "mostly" IEEE compliant if I recall.
+19:41 < matches> Well a picture tells a thousand words
+19:41 < matches> So I think I wrote 8000 words today
+19:41 < matches> Progress!
+19:43 <@sulix> http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/brw_defines.h?id=9d6166880da83887e3246fb4498c3a07d979cc3b#n162
+19:43 <@sulix> I'll see if I can find where they actually set it to non IEEE.
+19:43 < matches> Oh I was going to say fglrx did different things to nVidea but as I don't have nVidea that's difficult to do
+19:45 <@sulix> Although there's this: http://lists.freedesktop.org/archives/mesa-dev/2013-July/041555.html
+19:45 <@sulix> Yeah, nVidia, Intel and fglrx all seem to do different things.
+19:45 <@sulix> fglrx does the strangest things.
+19:45 <@sulix> nVidia does the most consistant things.
+19:45 <@sulix> Intel sits nicely in the middle.
+19:46 < matches> If we can get four screenshots of the different things at the same view bounds that might be useful
+19:47 < matches> Also working out more about what the jagged edges implies about the precision/rounding might be helpful
+19:47 < matches> All I've got is "This is clearly not a circle"
+19:48 < matches> So it's still doing that with the quad trees enabled, so I assume the quad trees aren't amazingly quadifying everything yet :P
+19:48 <@sulix> The quadtrees are basically doing nothing but occasionally causing bugs.
+19:48 <@sulix> http://davidgow.net/stuff/ipdf-nvidia.png
+19:48 < matches> That is progress at least
+19:49 < matches> Thanks
+19:49 < matches> I will update the others to be the same view bounds
+19:49 < matches> I *think* we have code to set the view bounds at start?
+19:51 <@sulix> http://davidgow.net/stuff/ipdf-intel.png
+19:51 < matches> Haha
+19:51 < matches> Well it's really obvious that that's different
+19:52 < matches> Can you rerun it with -b 0.0869386 0.634194 2.63295e-07 2.63295e-07
+19:52 < matches> Obsessive compulsive...
+19:52 < matches> Must all be same view bounds...
+19:53 < matches> I'd run it on my other laptop with intel integrated graphics except the keyboard still doesn't work
+19:55 < matches> Actually don't bother
+19:55 <@sulix> http://davidgow.net/stuff/ipdf-nvidia1.png
+19:57 <@sulix> http://davidgow.net/stuff/ipdf-intel1.png
+19:59 < matches> oah wierd stuff is happening with the quad tree
+19:59 < matches> There is a big circle and a little circle
+19:59 < matches> Is that supposed to be here...
+20:00 < matches> The distance between them is not constant :S
+20:09 <@sulix> Yeah, that doesn't happen on intel and is the bug I've been hitting my head against.
+20:09 <@sulix> Pretty certain I'm trying to render one more object than there actually is somewhere, maybe corruping memory in the process.
+20:32 < matches> Ok so it turns out the CPU is actually about as terrible as the GPU at those view bounds when you replace the "double" with "float" in the Circle Renderer :S
+20:32 <@sulix> That's what I expected.
+20:32 <@sulix> It looks like the nVidia one, right?
+20:32 < matches> But it does slightly different wrong things!
+20:34 < matches> It looks similar-ish
+20:35 < matches> It is blocky as opposed to zig zaggy
+20:39 < matches> As in it doesn't look as whack as intel
+20:43 <@sulix> Hmm... I'm not sure what I'm doing wrong, but I can't see any artefacts at all with CPU rendering w/ those bounds.
+20:55 < matches> They are hard coded as doubles
+20:55 < matches> Not floats
+20:55 < matches> Or reals rather
+20:56 <@sulix> Ah.
+20:56 <@sulix> This explains much.
+21:08 < matches> I have pushed a thing
+21:09 < matches> It almost sounds like a real paper
+21:09 < matches> Until you realise all it is is "we drew some circles and they look different"
+21:09 < matches> Also your screenshots had some kind of crazy blue glowy border
+21:10 <@sulix> Yeah, that's the KDE window shadow.
+21:10 < matches> Fancy
+21:10 <@sulix> It used to make the nVidia driver corrupt screenshots, but it seems to work now.
+21:11 < matches> I'm pretty pleased with that 4 way comparison figure...
+21:12 < matches> "One of these things is not like the others..."
+21:12 < matches> *cough* intel
+21:12 <@sulix> The conclusion is brilliant.
+21:15 < matches> If we assume the nVidia and x86-64 figures are what things are supposed to look like
+21:15 < matches> fglrx tries really hard
+21:15 < matches> But doesn't quite make it
+21:16 < matches> (I'm pretty sure that's just a particularly good view for it)
+21:16 < matches> (If you move it around it goes insane)
+21:16 < matches> I can respect the intel shader
+21:16 < matches> It isn't afraid to blatantly disregard the rules
+21:17 < matches> intel driver rather
+21:17 < matches> Not sure why I put "shader" there
+21:17 < matches> This has not been as productive as I hoped
+21:18 < matches> Still
+21:18 < matches> We finally have something written that Tim can pass judgement on
+21:18 < matches> He's still in the country right?
+21:19 < matches> He might want to finish passing judgement on my literature review first :S
+21:21 <@sulix> I think he's still in the country, but don't hold me to that.
+21:22 < matches> Ok, so if you translate around with the CPU things don't go insane, but they do on the GPU. That might be caused by something else though.
+21:23 < matches> I'll be at University tomorrow
+21:24 <@sulix> I might head in, too, then.
+21:25 <@sulix> Do things still "go insane" on the GPU with CPU-side coordinate transforms.
+21:26 < matches> Yeah
+21:26 < matches> It looks like there is a tear
+21:27 < matches> So you get this rectangle pattern
+21:27 < matches> If you move it around on the CPU it maintains its shape
+21:28 <@sulix> I think that fglrx (or maybe just the AMD hardware) calculates the coordinates per-triangle rather than per-vertex or something.
+21:28 < matches> Under fglrx the bottom part of it sort of maintains its shape but there is a big diagonal line and the stuff above that changes
+21:28 <@sulix> That's pretty weird.
+21:29 < matches> Also the bottom part doesn't have concave bits but the top occasionally gets one
+21:29 < matches> concave/overhanging whatever
+21:29 <@sulix> The whole thing maintains its shape on nvidia (and even intel)
+21:29 < matches> Well, the bottom half (and also the CPU/nVidia entire thing) looks kind of like a stair case
+21:29 < matches> The top bit gets all these sticky out bits and overhangs
+21:30 < matches> Which brings us to our next paper
+21:30 < matches> The geology of fglrx
+21:30 <@sulix> Intel also does the "staircase" on the other side of the circle.
+21:30 < matches> On the other side...
+21:30 < matches> Hmm the plot thickens
+21:31 < matches> Oh well I need to sleep
+21:31 < matches> Why do I feel like I have actually lost sleep over the holidays...
+21:32 < matches> I am not ready for semester to start :(
+21:32 <@sulix> I know exactly what you mean.
+21:33 < matches> I seem to have been roped into unpaid work with physics
+21:34 <@sulix> Oh dear. More lab demonstrating or something more interesting?
+21:34 < matches> Hopefully if I visit ECM they won't make me do GENG5505 yet
+21:34 < matches> Fixing my honours experiment I think...
+21:35 <@sulix> Another pipe corroded through?
+21:35 < matches> Haha
+21:35 < matches> They were wondering where all the electronics went
+21:35 < matches> (I have most of it)
+21:35 < matches> (Also it's no longer functional)
+21:36 < matches> (I may have taken some of it apart...)
+21:36 < matches> (Although really the sensible option would have been to burn it with fire)
+21:37 < matches> Goodnight anyway
+21:37 <@sulix> I'm required to "correct" anything they want to change with this project after submitting it.
+21:37 <@sulix> On the morrow, then!
+--- Day changed Fri Jul 25 2014
+11:24 < matches> I'm at UCC
+11:39 <@sulix> Okay, I'll show up once I've sorted out this acedemic record stuff.
+12:05 < matches> I went to ECM but apparently just a few other people are having difficulties...
+18:24 < matches> So steam browser supports html5 canvas but not keyboard events
+18:24 < matches> This seems to happen with a lot of browsers
+18:25 < matches> We support html5 canvas (which is pretty much solely designed for web based games)
+18:25 < matches> But we don't support any way to actually pass input to the page that doesn't suck
+18:25 < matches> (I'm looking at you Safari)
+18:31 < matches> It sort of spoils the "HTML5 is AWESOME" message the HTML5 people are aiming for
+18:31 < matches> The best bit of html5 is <canvas> and that you no longer need to use html because you can just draw everything in the canvas...
+18:32 < matches> Which is scarily similar to using PostScript
+--- Day changed Mon Jul 28 2014
+10:05 < matches> In 2.07 now
+10:07 < matches> You removed SDL from contrib
+10:07 < matches> So now it won't compile on the lab machines
+10:07  * matches gets out the laptop then
+--- Day changed Tue Jul 29 2014
+09:59 < matches> I seem to have this bizarre illness
+10:00 < matches> Where half my head feels fine
+10:00 < matches> And the other half feels like I've been trying to read brainfuck
+10:00 < matches> I hope you don't catch it
+10:00 < matches> The side that is sick is the side that was closest to the group hug
+10:00 < matches> Coincidence!?
+10:00 < matches> I think not!
+10:08 < matches> You know how there's this theory about the two halves of the brain being semi independent and sort of subconsciously able to think by themselves
+10:08 < matches> I think the left side of my brain is dead
+10:08 < matches> It's not responding to pings
+10:09 < matches> I think the project working side might be the alive one though, so we shall see if I can actually do something useful
+--- Log closed Tue Jul 29 23:13:08 2014
+--- Log opened Wed Jul 30 12:03:38 2014
+12:03 -!- matches [matches@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
+12:03 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
+12:03 -!- Irssi: Join to #ipdf was synced in 0 secs
+16:28 -!- sulix [sulix@motsugo.ucc.gu.uwa.edu.au] has quit [Ping timeout: 121 seconds]
+17:25 -!- sulix [sulix@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
+--- Day changed Sun Aug 03 2014
+12:43 < matches> So I found my moronic mistake with the virtual FPU and it seems to actually work
+12:44 < matches> I think it's even slower than using Rational<Arbint>
+12:44 < matches> Unless everything's slow because of the QT now
+12:45 < matches> There's an awful lot of "Rendering QT node" debug
+12:46 < matches> No its the VFPU that makes sense
+12:47 < matches> Since every floating point operation now requires writing 18 hex characters over a unix domain socket
+12:47 < matches> Hooray VHDL
+12:48 < matches> (I'm sure if you have $$$$ and like Enterprise(TM) software VHDL is great)
+12:48 < matches> I'll just do some miscellaneous things and hopefully some of them will be useful
+12:48 < matches> Bye
+14:14 < matches> So with the VFPU and doing everything on the GPU we have 2.2 FPS
+14:14 < matches> It seems to be able to cope with rectangles on the CPU
+14:15 < matches> The circle may present some difficulties
+14:16 < matches> It would be have been pretty cool to change the vfpu and see if anything makes it look like intel
+14:16 < matches> But ultimately useless I suppose
+14:37 < sulix> There might be some info in the hardware docs, though they're pretty incomprehensible: https://01.org/linuxgraphics/documentation/2013-intel-core-processor-family
+14:38 < sulix> AMD also have manuals: http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/
+14:38 < sulix> nVidia are sworn to secrecy.
+--- Day changed Tue Aug 05 2014
+12:38 < matches> I'm looking at the atril source
+12:38 < matches> To see if I can compile it without the oppressive 400% max zoom
+12:39 < matches> It is rather intense
+12:39 < matches> I think the zooms are set depending on the language?
+12:41 < matches> There are po files which are definitely not position independent object files
+12:43 < matches> #define ZOOM_MAXIMAL(zoom_levels[n_zoom_levels - 1].level)
+12:43 < matches> The plot thickens!
+12:45 < matches> Heh this is actually sort of making sense
+12:45 < matches> They have a "cut-n-paste/zoom-control" directory
+12:48 < matches> I'm confused as to how the maximum zoom is 6400% and yet my version will only zoom to 400%
+12:48 < matches> But I guess I shall compile it from source and see what actually happens
+12:51 < matches> They also have a script to configure their configure script...
+12:51 < matches> Oh dear xml is involved
+12:53 < matches> There needs to be a way to save the status of configure so you don't have to rerun it from scratch every time you fix an error
+12:56 < matches> Our document viewer may only be able to render beziers and circles
+12:56 < matches> But at least it doesn't have any dependencies!
+12:56 < matches> Well many
+12:56 < matches> I suppose since SDL is in contrib we should put GMP in contrib too
+12:57 < matches> But yes, I don't care about caja plugins dammit I want to zoom on a pdf
+13:00 < matches> "Warning: Comparison between pointer and integer"
+13:00 < matches> Aaaah
+13:00 < matches> It compiles...
+13:01 < matches> But where did it put the binary...
+13:02 < matches> Oh great it expects things to be in /usr
+13:03 < matches> I guess I will run "install-sh" and hope I will still have a usable pdf viewer
+13:07 < matches> There's a LOT of G_ and g_ variables
+13:07 < matches> Actually functions
+13:07 < matches> I think g_ does not mean global in this context
+13:07 < matches> Maybe
+13:11 < matches> So it's not just a matter of ZOOM_MAXIMAL being redefined to ridiculously huge numbers having any effect
+13:11 < matches> I guess they use some other library that has zooming
+13:13 < matches> It somehow detects what the maximum zoom should be based on the document as well
+13:13 < matches> This is just over engineering!
+13:19 < matches> ev_view_can_zoom_in (EvView *view)
+13:19 < matches> return view->scale * ZOOM_IN_FACTOR <= ev_document_model_get_max_scale (view->model);
+13:19 < matches> Let
+13:19  * matches casually makes it return true
+13:19 < matches> Also wtf
+13:19 < matches> They have a "gboolean" type
+13:19 < matches> Is "bool" inferior?
+13:19 < matches> What more do you need than true and false
+13:20 < matches> Is bool used as a variable name for something
+13:20 < matches> sigh
+13:24 < matches> No ok it still won't let me zoom in more
+13:25 < matches> g_return_if_fail in the zoom functions
+13:25 < matches> They don't look important
+13:28 < matches> There are a surprising amount of places with a "if zoom or scale is bigger than the maximum, return"
+13:28 < matches> Like, are three checks really necessary
+13:29 < matches> I think you can set model->sizing_mode to "EV_SIZING_FREE" but I have no idea what that will do
+13:29 < matches> So I'll just continue commenting out anything that looks like it will return early from the zoom process...
+13:30 < sulix> Sounds like a plan!
+13:31 < matches> The use of g_ for function names makes me want to stab someone :P
+13:31 < matches> I assume it's related to gtk or maybe just gnome
+13:32 < matches> Also about half their doubles are "gdouble"
+13:32 < matches> And the other half are "double"
+13:32 < matches> :S
+13:32 < sulix> gtk had their own crazy, let's implement everything from scratch idea.
+13:32 < sulix> They have their own "classes" in C, IIRC.
+13:32 < matches> It's pretty object orientated yes
+13:34 < matches> Ok I seem to now be able to zoom in a *bit* more and then it just stops drawing things
+13:35 < matches> No wait it's just hopelessly slow
+13:37 < matches> It also zooms in on the wrong spot and then draws it and then moves the view back to the mouse and draws again
+13:38 < matches> But yes, it doesn't cope well with zooming at all
+13:38 < matches> I was kind of hoping it would work
+13:39 < matches> Maybe if I use a simpler document
+13:43 < matches> Congratulations anyway
+13:43 < matches> We can zoom further on a circle than atril can
+13:44 < matches> Unfortunately the reasons atril can't zoom are probably not related to precision
+13:44 < matches> Maybe I need to find some "if zoom > thing don't draw anything" and comment those out too
+13:44 < matches> Sigh
+14:07 < matches> It is resistant to my valgrind attempts
+14:07 < matches> It seems to have spawned 9 processes
+14:10 < matches> Oh "atril" is actually a series of hideous bash scripts that load libraries or something
+14:12 < matches> You know
+14:12 < matches> I'm sure if we tried
+14:12 < matches> We could make a less shitty pdf viewer out of our program
+14:29 < matches> Interesting
+14:30 < matches> "ev_document_render" got called 10.6 Billion times
+14:30 < matches> I don't think I changed the view that many times...
+14:32 < matches> Ok, so just working on our own viewer is probably better at this point than working out why atril has a heart attack if you zoom
+14:33 < matches> I'm going to pretend this wasn't a waste of time...
+14:41 < matches> "existing pdf viewers cap the view because otherwise they break due to bugs that aren't actually related to precision"
+15:43 < matches> So I suspect the GPU Bezier rendering is buggy
+15:44 < matches> Or maybe it's a quad tree thing
+15:45 < matches> Or both...
+15:46 < matches> I'm pretty sure the appearance of an individual bezier should not depend on what other beziers are in the document :P
+15:47 < matches> Yeah there's wierd quad tree shit going on
+15:48 < matches> I'm going to try and add some sort of glyph/font like thing
+15:49 < matches> It's either that or create hand drawn beziers in the current view
+15:50 < matches> But I feel it desperately needs an example of being able to actually zoom in and create something at an "arbitrary" level
+18:54 < matches> So we sort of have a very broken, very badly written, SVG parser
+18:55 < matches> A bunch of bugs showed up in the bezier rendering
+18:56 < matches> Although it might just be fglrx
+22:23 < sulix> The GL code is now consistantly broken, rather than sporadically broken.
+22:24 < sulix> Trying to render SVGs with it might count as modern art, though.
+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<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. :)
+--- 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