From: C R Onjob Date: Tue, 17 Jun 2014 17:00:02 +0000 (+0800) Subject: Automatic commit of irc logs X-Git-Url: https://git.ucc.asn.au/?p=ipdf%2Fdocuments.git;a=commitdiff_plain;h=d2c2e63b709c81b797faa4e8c1ed70269339fe1b 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 --- 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...