From: C R Onjob Date: Tue, 5 Aug 2014 17:00:02 +0000 (+0800) Subject: Automatic commit of irc logs X-Git-Url: https://git.ucc.asn.au/?a=commitdiff_plain;h=8c09e7dd80d75c4972f2f9fc27df1a01ee7229e8;p=ipdf%2Fdocuments.git Automatic commit of irc logs Patch griefs with proverbs. -- William Shakespeare, "Much Ado About Nothing" --- diff --git a/irc/#ipdf.log b/irc/#ipdf.log index ec37901..45b1eae 100644 --- a/irc/#ipdf.log +++ b/irc/#ipdf.log @@ -3176,3 +3176,102 @@ 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