Automatic commit of irc logs

You will become rich and famous unless you don't.

diff --git a/irc/#ipdf.log b/irc/#ipdf.log
index d757461..c9ad2dc 100644 (file)
--- a/irc/#ipdf.log
+++ b/irc/#ipdf.log
@@ -1865,3 +1865,112 @@
 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...