22:51 <@matches> I guess it doesn't matter, clearly the lit review was not intended for anyone to actually read
23:42 <@matches> I suspect RenderPixels doesn't work
23:45 <@sulix> This may be the case.
+--- Day changed Tue Jun 17 2014
+01:05 <@matches> Behold the magnificence of CPU based rendering
+01:06 <@matches> In which we pass a massive pixel array to the ObjectRenderer's and just save it to a BMP
+01:06 <@matches> Because OpenGL
+01:06 <@matches> I'll probably fix it later
+01:11 <@matches> Whoops seg faults ahoy
+01:12 <@matches> Wait I swear it wasn't segfaulting before I commited that
+01:19 <@matches> It segfaults sometimes depending on where you have the view. If you just have one circle and zoom in you can see the amazingly less jagged looking lines.
+01:19 <@matches> That, is a certified result
+10:13 <@sulix> I got the CPU rendered version to show up on the screen.
+10:14 <@sulix> RenderPixels was pretty broken.
+10:38 <@matches> Nice
+10:39 <@sulix> I think the segfaults are it trying to draw outside of the display.
+10:39 <@matches> Yeah
+10:39 <@sulix> I haven't managed to zoom in too much yet.
+10:39 <@matches> My clipping is probably wrongish
+10:40 <@matches> fonttex_frag.glsl? Fear
+10:40 <@sulix> Yeah, the "basictex_frag" file did a bunch of pretty font-specific things.
+10:40 <@matches> Ah
+10:43 <@sulix> The CPU renderer also shows some random lines when there are no outlines on the screen.
+10:43 <@matches> Is it just me or does it look slightly nicer on the CPU when zoomed out a bit
+10:44 <@matches> Well it looks different
+10:44 <@matches> I can't quite work out whether it looks nicer or worse :P
+10:44 <@sulix> Okay, it doesn't segfault if the rectangle outlines are disabled.
+10:45 <@matches> Ah
+10:45 <@matches> Yeah it is setting top/bottom/left/right outside the pixels
+10:45 <@sulix> I think there are just some slightly different edge-case rules when zoomed out.
+10:47 <@matches> With my skills at writing renderers I should be working on the fglrx drivers
+10:47 <@matches> :P
+10:47 <@sulix> Things vanish if you zoom in too much, too.
+10:48 <@matches> Blame it on floats
+10:49 <@matches> The CPU renderer is using a width of 1 pixel less than it should be
+10:49 <@sulix> Why are the floats sinking? :P
+10:49 <@matches> That's unrelated
+10:49 <@matches> It's probably an integer rounding issue somewhere
+10:49 <@matches> When the view gets big something goes to zero
+10:50 <@matches> The CPU renderer transforms everything to pixel positions and then renders using those
+11:02 <@matches> The GPU renderer occassionally leaves off the corners of things
+11:02 <@matches> I never noticed before
+11:02 <@matches> Anyway I think the segfaults are fixed
+11:03 <@matches> Looking at the mysterious disappearances next
+11:04 <@matches> It's integer overflow!
+11:04 <@matches> Facepalm
+11:05 <@sulix> Is it int64_t time?
+11:05 <@sulix> Or magic huge bigint time?
+11:05 <@matches> No I don't think that's necessary
+11:06 <@matches> If the transformed width is smaller or larger than the width of the screen you can surely just ignore it
+11:06 <@matches> Well, depending on what you are drawing
+11:08 <@matches> Well it does matter unless you do some clever maths
+11:08 <@matches> The clever maths was your part of the project...
+11:09 <@matches> So I will just make them int64_t for now
+11:50 <@matches> Pushe
+11:50 <@matches> *d
+11:50 <@matches> I should probably just make all the coorinates into Real instead of int64_t actually
+12:03 <@sulix> Wow: this is pretty awesome.
+12:03 <@sulix> I still get the artefacts, but I have to zoom in a lot more.
+12:03 <@matches> Haha
+12:04 <@sulix> Also, the CPU rendering artefacts and the GPU rendering artefacts are pretty similar on my machine, so it looks like it's just precision causing them.
+12:04 <@matches> That is nice
+15:20 <@matches> I'm trying to do a performance graph. Gnuplot doesn't like it much
+15:20 <@matches> Well actually it's python's crappy interface to gnuplot that doesn't like it
+15:23 <@matches> ... tempted to implement the performance graph in ipdf...
+15:23 <@matches> Just keep adding circles to the document
+15:24 <@matches> So meta
+15:25 <@matches> We need a cool performance graph-y thing
+15:26 <@matches> I think doing it in OpenGL is going to be the least shitty way actually
+15:26 <@matches> This is a wheel that's probably been invented but it was invented wrong
+17:11 <@matches> I've got a performance graph sort of working
+17:11 <@matches> It almost looks like we are doing real science!
+17:13 <@matches> I think we'll need to put some effort into our data analysis though because it's extremely noisy
+17:13 <@matches> Smoothing averages or something
+17:13 <@matches> Smoothing averages are the best
+17:14 <@matches> They make any data look amazing
+17:15 <@matches> Anyway, CPU rendering is only worse than GPU rendering when you force re-rendering
+17:16 <@matches> So well done with the amazingly efficient cached frame buffer
+17:18 <@matches> We can probably make it draw every frame both on the CPU and GPU to compare them in real time
+17:18 <@matches> The possibilities are limitless!
+17:19 <@matches> Graphs graphs graphs!
+17:20 <@matches> Also I did end up using Gnuplot and python (sorry) but I made it slightly less shitty
+17:27 <@matches> I have pushed things
+17:27 <@matches> Also we probably don't need all three of those ways to measure performance
+21:00 <@sulix> I got the graphs working on my laptop: very nice.
+21:00 <@sulix> I can see how more GPU time is used with GPU rendering and more CPU time with CPU rendering quite well, actually.
+21:59 <@matches> So the objects all being in one structure of arrays is sort of inconvenient because the size of objects has to be constant
+21:59 <@matches> Also the size of Real has to be constant
+22:03 <@matches> I guess we could have union {Rect rect, Bezier bezier} and do rectangles and Beziers in the same thing but that is slightly terrifying
+22:04 <@matches> But there's still the problem of Real because as soon as Real becomes arbitrary precision it will start allocating memory and not be fwrite/fread'able
+22:04 <@matches> :S
+22:05 <@matches> You'll still want the struct of arrays because that will make view reparenting much easier
+22:05 <@matches> Gah
+22:06 <@sulix> I'm tempted to just split it by type: Have an array of Rects, an array of Béziers, an array of Circles, etc.
+22:06 <@matches> Yeah but you need to store an "indexes" array as well
+22:06 <@matches> But that might be the least terrible
+22:07 <@matches> Yes that should work
+22:07 <@matches> Our fwrite/fread is still doomed though
+22:07 <@matches> When shit gets Real
+22:07 <@sulix> Yeah, you'd need some indices one way or another.
+22:08 <@sulix> And yeah, we'll need a massive "ConvertWhateverRealIsStoredInTheFileToWhateverRealIsDefined" function or something.
+22:08 <@matches> That will totally be its name
+22:08 <@sulix> (Some old compilers had function name limits... I wonder if modern gcc has)
+22:09 <@sulix> (There is but one way to find out!)
+22:09 <@matches> We don't need an array of circles/ellipses since we get those for free with Rect. Unless you want circular arcs as well as bezier curves
+22:10 <@matches> Which you probably will? So you can approximate beziers
+22:10 <@matches> Anyway I'll worry about adding Beziers first and once we've worked that out others should hopefully be easier
+22:11 <@matches> I was sort of thinking it would be good to be able to define groups of objects as a special object type
+22:11 <@matches> Then you can make paths out of your beziers
+22:11 <@matches> But they won't be fixed size
+22:12 <@matches> Anyway I will see if you have magically solved the problem for me in the morning :P
+22:14 <@sulix> I wouldn't count on it...
+--- Day changed Wed Jun 18 2014
+16:50 <@matches> Behold, the glory of Beziers and Bresenham!
+16:50 <@matches> Breseniers I shall call them
+16:54 <@matches> I'm getting a very strong vibe of "Reinventing graphics technologies from the 1990s" at the moment
+16:55 <@matches> I should probably look at floating point some more
+16:55 <@matches> And reinvent numerical computation technologies from the 1980s
+16:56 <@matches> We need a GPU renderer for the Beziers, and we need to fix save/load to not assume everything is a fixed size, and ...
+16:56 <@matches> Argh
+16:56 <@matches> All the things
+17:00 <@matches> Maybe I'll multithread the CPU rendering too, just to make things more difficult :P
+22:48 <@sulix> So I got some béziers rendering on the GPU.
+22:48 <@sulix> They're not the ones in the document, and they're not in the right spots, though.
+23:12 <@sulix> First 3 béziers are rendering properly on the GPU, then we get corrupted memory or something.
+23:14 <@sulix> Ah: I see, I need some way of uploading which bézier IDs are being used.
+23:41 <@sulix> Okay, Béziers now render on the GPU as well.
+23:43 <@sulix> The code is a little bit ugly, and for that I am sorry, but blame the fact that the GL feature that makes this nice is only about a year old and so nothing supports it.
+23:43 <@sulix> So we're basically uploading all of the raw document data into a huge texture.
+23:47 <@sulix> (If you ask me, the GPU ones also look slightly nicer, though that's probably a bug)
+--- Day changed Thu Jun 19 2014
+13:55 <@matches> From those papers I was under the impression just rendering a bezier on a GPU was an impressive feat, so well done :P
+13:57 <@sulix> (It's basically just a direct port of your CPU implementation, tbh)
+13:59 <@matches> When I zoom out the GPU ones look nicer, there's probably something wrong with my Bresenham implementation
+13:59 <@matches> Although it was mostly shamelessly copied from "Computer Graphics"
+13:59 <@matches> Except they were like "Here it is for 0 < m < 1, the rest can be done by symmetry"
+14:02 <@matches> The lines definitely have gaps on the CPU, and they also seem too thick as you zoom out
+14:02 <@matches> Having said that, I don't think the GPU starts at x0,y0
+14:03 <@matches> Anyway I'm going to implement a Rational number type and see if anything exciting happens (that's how you do research right?)
+14:06 <@matches> Fortunately I sort of did most of this for one of the codejam problems (where it turned out I didn't really need Rational numbers but I thought I did)
+14:20 <@sulix> Fixed the missing bit off the end.
+16:43 <@matches> I suspect Rationals are either not a very good idea, or there is a bug in one of my fundamental operations
+16:43 <@matches> +, -, *, / are hard
+16:56 <@sulix> Is it at least a pretty bug?
+16:59 <@matches> Um...
+16:59 <@matches> No
+17:00 <@matches> It seems buggy for anything other than the {0,0,1,1} starting view
+17:14 <@matches> I suspect it's the expf in the mouse wheel scrolling
+17:14 <@matches> Since you know, exp is definitely not a rational number...
+17:15 <@matches> Hmm, but it shouldn't matter because it will just convert to the nearest rational number
+17:16 <@matches> ie: p = (int64_t)(whatever*1e10) q = (int64_t)1e10
+17:28 <@matches> Oh
+17:28 <@matches> Oh
+17:28 <@matches> Head -> Desk
+17:28 <@matches> Rational & operator*=(const Rational & r) {this->operator=(*this*r); return *this;}
+17:28 <@matches> Rational & operator/=(const Rational & r) {this->operator=(*this*r); return *this;}
+17:29 <@matches> Rational & operator-=(const Rational & r) {this->operator=(*this+r); return *this;}
+17:29 <@matches> I think the worst part is that I actually said "It is probably a bug in my +,-,*,/
+17:29 <@matches> And it still took me this long to notice
+17:30 <@matches> The second worst thing is I've made that sort of mistake like 1000 times before
+17:30 <@matches> The third worst thing is I am recalling that article where the guy says "At least plus and times are sort of the same thing"
+17:30 <@sulix> Feel the power of copy and paste flowing through you.
+17:32 <@matches> Well let's not celebrate just yet, the view still goes to shit. Just slightly slower :P
+17:33 -!- matches changed the topic of #ipdf to: NaNpdf
+17:33 <@matches> Our document supports a view of {-inf,-inf,nan,nan} thus making it truly infinite precision
+17:34 <@sulix> I had that happen a lot when I was writing the original zoom code.
+18:19 <@matches> So I suspect that Rationals are just a really shitty number representation :P
+18:20 <@matches> Specifically, you get integer overflows really really fast
+18:20 <@matches> And if you are going to have a Rational that's BigInt / BigInt you may as well just have a BigFloat
+18:21 <@matches> The ancients were probably right.
+18:21 <@matches> When they decided not to use rationals.
+18:23 <@matches> I guess floats are rationals technically, I mean the representation using P/Q
+18:23 <@matches> I kind of wish I'd done some pure maths here...
+18:23 <@matches> Or paid more attention in second year
+18:28 <@matches> At least I sort of have conclusive evidence that rationals suck. As opposed to "it should be obvious to anyone with half a brain"
+19:00 <@sulix> Floats are not rationals.
+19:00 <@sulix> Not exactly.
+19:01 <@sulix> Something which can be stored in a finite amount of space as a rational cannot always be stored in a finite amount of space as a float, but not vice-versa.
+19:01 <@sulix> e.g.: 1/3
+19:04 <@sulix> Basically floats = rationals where the denominator must be a power of two.
+19:05 <@sulix> (Of course, these are all the same in the limit, but the limit of a cauchy sequence of rationals gives the reals, so the point is kinda moot, there, anyway)
+19:18 <@matches> Yeah floats are a subset of the rationals I think I meant
+--- Day changed Sat Jun 21 2014
+16:22 <@matches> So I got a new smartphone today... I'm having fun trying to zoom in on things
+16:24 <@matches> Actually the zooming isn't annoying so much as the needing to pan around to view all the text in a pdf
+16:25 <@matches> This is what I get for buying the cheapest phone with the lowest resolution they had :P
+16:26 <@matches> I didn't want to get one more expensive than my old one because I'm still convinced I will get around to fixing it one of these days
+16:26 <@matches> Or months. Or years. But eventually.
+--- Day changed Mon Jun 23 2014
+11:51 <@matches> The meeting happened at ~11:30
+12:49 <@sulix> Oh damn. I thought there wasn't going to be one today.
+12:49 <@sulix> What did I miss?
+13:04 <@matches> Basically I told him what we'd done
+13:05 <@matches> Which was rendering on CPU or GPU, and Beziers (but only degree 2)
+13:06 <@matches> And I implemented Rationals but they are terrible, so he sent me some code from an ACM competition about approximating things with Rationals
+13:13 <@sulix> Some javascript guy is trying to convince people that the only numeric data type should be some custom 64-bit decimal thing.
+13:13 <@sulix> A lot of people have started quoting Kahan at him.
+13:20 <@matches> Haha
git.ucc.asn.au / ipdf / documents.git / blobdiff
UCC git Repository :: git.ucc.asn.au