+--- Day changed Mon Jun 16 2014
+14:49 <@matches> Some of this OpenGL stuff doesn't quite add up
+14:49 <@matches> Like m_cahed_display.UnBind(); m_cached_display.Blit();
+14:50 <@matches> Oh
+14:50 <@matches> I see
+14:50 <@matches> There is a difference
+14:51 * matches -> OpenGL documentation
+14:53 <@matches> Right I see
+15:03 <@matches> Well, this makes a lot more sense than tpg's "Adventures in VEMS" in #ucc at least
+15:18 <@sulix> Well that's an achievement, I guess.
+15:18 <@sulix> Also http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf
+15:18 <@sulix> It's the spec for "nullptr"...
+15:20 <@matches> "Pointers are pretty cool. Pointers that are NULL are pretty cool. We address these issues by proposing nullptr" ?
+15:21 <@sulix> Haha: Pretty much.
+15:22 <@matches> Why not just reserve the word "null"
+15:22 <@matches> I could get behind it then
+15:23 <@matches> It is not a null reference
+15:23 <@matches> But if you ever have a null reference something is horrifyingly wrong
+15:23 <@matches> Bah humbug
+15:24 <@sulix> They have a page about that where they said "everyone was naming their variables \"null\"".
+15:24 * sulix realises he just escaped those quote. Oh dear.
+15:24 <@matches> A valid point, which should have lead to "Everyone are morons"
+15:24 <@matches> Fun fact
+15:25 <@matches> Matlab (like fortran actually) will let you use key words as variable names.
+15:25 <@sulix> "It's a feature!"
+15:25 <@matches> Question on CITS2401 exam: "Why is 'ii' preferred over 'i' and 'jj' over 'j' for loop iteration?"
+15:26 <@matches> Both i and j are the complex number sqrt(-1)
+15:27 <@matches> It seems like naming it 'nullptr' instead of 'null' missed an opportunity to stop people naming their variables really confusing things :P
+15:30 <@matches> Well I am infinitely wiser about nullptr now but I don't think it will stop me just using NULL
+16:15 <@matches> This is slowly starting to make sense
+16:35 <@matches> I'm having a bit of difficulty because it's all so optimised for the GPU
+16:35 <@matches> I think what we need is an ObjectRenderer class or similar
+16:36 <@matches> Have one for each type of object and implement RenderUsingGPU and RenderUsingCPU
+16:36 <@matches> I will see what monstrosity I can come up with
+16:36 <@matches> But a lot of that code for the circles and rectangles is exactly the same just copied and pasted with different variable names
+16:37 <@matches> I think there is an official software engineering term for that sort of thing...
+16:46 <@matches> Alright, breaking everything
+16:46 <@matches> This will probably take a while
+16:47 * matches dreads merges
+17:02 <@sulix> Yeah, I was going to basically end up with an ObjectRenderer class, too.
+17:02 <@sulix> So I'll leave it to you for now and procrasinate from doing my maths in some other way.
+17:07 <@matches> Cool :)
+17:52 <@matches> Now I'm not very strict about the whole RAII thing myself, but there seem to be some cases where things can probably just go in the constructor?
+17:52 <@matches> I guess we can fight about those later
+17:54 <@matches> I guess I can see us wanting to set m_render_inited to false and have it automatically recreate everything, maybe, but I can't see a case where we will want to recompile the shaders, so I am going to put the shader initialisation in the constructors
+17:54 <@matches> I have gone mad with power
+17:54 <@matches> Maaad
+20:30 <@matches> This ObjectRenderer is like a two headed hydra
+20:31 <@matches> I thought about using just the ibo and vbo and getting the indices out of it, but that's a bit terrible
+20:31 <@matches> So it will have an ibo for the GPU and an array for the CPU
+20:35 * sulix thinks this makes sense.
+21:47 <@matches> Good news! I have things on the screen. Bad news. They are still on the GPU and they are wrong.
+21:49 <@matches> More coffee required...
+21:58 <@matches> Not sure if code wrong or fglrx having an existential crisis
+22:04 <@matches> Unrelated to the segfaults of doom, but I just realised that there's all this interest in using GPUs for scientific computation, and everything seems to point to them having vastly inferior floating point computation to a CPU, which is a bit disconcerting
+22:05 <@matches> I imagine the OpenCL libraries etc actually use the IEEE floating point capabilities? I hope?
+22:05 * matches files under "beyond the scope of project"
+22:06 <@sulix> If you commit code I can test it on non-fglrx if that'll help.
+22:06 <@matches> I'd rather not commit it just yet, I am 90% sure it is something I have done wrong and don't want to shame myself by committing broken code
+22:06 <@matches> It'd be like vomiting all over the codebase
+22:07 * sulix is pretty sure half of his commits broke something.
+22:29 <@matches> Ok I committed stuff that should in theory work with the test pattern again
+22:30 <@matches> Using new and improved ObjectRenderer classes
+22:30 <@matches> For some definition of improved
+22:30 <@matches> It doesn't actually use the CPU yet
+22:30 <@matches> It'll get there
+22:33 <@matches> You can go and add your MandleBrotSetRenderer now though :P
+22:36 <@sulix> Cool.
+22:37 <@sulix> The circles do trigger that intel driver bug again, though...
+22:38 <@matches> Ah damn
+22:38 <@matches> Would making CIRCLE_FILLED the first ObjectType fix that?
+22:38 <@sulix> It does.
+22:38 <@sulix> (I just checked)
+22:38 <@sulix> Yay intel!
+22:39 <@matches> Haha
+22:49 <@matches> Hey, does our rendering approach completely break compositing?
+22:49 <@matches> Render all circles
+22:49 <@matches> Then render all rectangles...
+22:49 <@matches> There's no depth...
+22:49 <@sulix> Um, maybe.
+22:49 <@matches> :P
+22:49 <@matches> I was just worrying about how to make compositing work using the CPU
+22:49 <@matches> and then I realised it won't work using the GPU as it is either
+22:50 <@sulix> If we're not doing alpha-blending, we could just add a z-coordinate and use the z-buffer.
+22:50 <@sulix> Otherwise, they need to be sorted if they intersect.
+22:50 <@matches> Let's not worry about this for now...
+22:50 <@matches> Even though I spent a rather significant part of my lit review explaining how awesome compositing is
+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...