| | <<<Back 1 day (to 2013/05/02) | 2013/05/03 |
| kens | Robin_Watts : tor8 after your recent discussions here: http://stackoverflow.com/questions/16351323/how-to-implement-double-tap-zooming-in-mupdf | 07:56.06 |
| Robin_Watts | kens: lalala I can't hear you. | 09:14.35 |
| Robin_Watts | touches nose. | 09:14.38 |
| kens | Its in writing :-) | 09:14.46 |
| | You oculd always direct the poster to the IRC conversaTION | 09:15.35 |
| Robin_Watts | tor8: ping | 10:29.43 |
| tor8 | Robin_Watts: pong. | 10:30.36 |
| Robin_Watts | so, the mesh stuff is ready for you to look at, and I'm going to have another crack at making the rtl stuff work on linux. | 10:31.18 |
| | s/linux/android/ | 10:31.22 |
| tor8 | Robin_Watts: okay. I'm just about to go for lunch. | 10:32.40 |
| Robin_Watts | tor8: ok. | 10:32.47 |
| | just didn't want to waste time on the android stuff if you'd already done it. | 10:33.06 |
| tor8 | I have not | 10:33.50 |
| Robin_Watts | I got bored. MuPDF can now open jpegs/pngs/tifs. | 12:08.11 |
| Robin_Watts | does the Tor summoning dance. | 12:09.56 |
| Robin_Watts | wins. | 12:10.09 |
| | tor8: The crash with text extraction on android is actually a crash with text extraction anywhere. | 12:10.33 |
| tor8 | ah. | 12:10.53 |
| Robin_Watts | the linkedl ist rework now results in it running off the end of the linked list. | 12:10.59 |
| | Also, there is a review for you on robin/master that makes mupdf cope with pngs/tifs/jpgs. | 12:11.23 |
| tor8 | .jfif-tbnl? | 12:12.19 |
| | never seen that before, what is it? | 12:12.26 |
| Robin_Watts | I found a page that listed mimetypes/file extensions, and that was in there :) | 12:12.45 |
| | Got some feedback from 530 about the mesh stuff. | 12:14.22 |
| | If they cut the subdiv level down to 1 they still see some white pixels (but then their data is bad) | 12:14.53 |
| | the previous code managed it in 2.7seconds with div=1. The new one takes 3.7s | 12:15.22 |
| | I suspect that that's a reasonable price to pay for the improvement. | 12:15.44 |
| tor8 | it should be less | 12:16.01 |
| Robin_Watts | They are still evaluating it, so I may get more feedback this evening. | 12:16.08 |
| | tor8: why should it be less ? | 12:16.15 |
| tor8 | the only thing we've really changed is not rounding | 12:16.22 |
| Robin_Watts | the new code keeps the X and Y in fp all the time. | 12:16.40 |
| tor8 | the edge stepping and scanline filling should be the same | 12:16.42 |
| | we can make the edge stepping all fixed point | 12:16.53 |
| Robin_Watts | We can't, easily. | 12:16.58 |
| | Radial fills use "MAXNUM" (32768 or something) | 12:17.24 |
| tor8 | I don't understand how your paint_scan can work... dc[k] is an inte | 12:17.27 |
| | int | 12:17.29 |
| Robin_Watts | tor8: right. it's fixed point. | 12:17.44 |
| | 16.16 fixed point. | 12:17.57 |
| tor8 | so v0 and v1 are fixed point coming in? | 12:18.03 |
| Robin_Watts | Yes. | 12:18.17 |
| tor8 | right. | 12:18.21 |
| Robin_Watts | v0/v1 in paintscan are e0/e1 from the calling routine. | 12:18.46 |
| | which are the 'prepared' values from the v[top] v[mid] v[bot] in the original | 12:19.15 |
| tor8 | it's easy to tell your code and my code apart. you always use do/while, I never use do/while :) | 12:20.14 |
| Robin_Watts | using 16.16 fixed point for the X and Y edges failed, due to X overflowing because of the maxnum stuff on the extended radial stuff. | 12:20.24 |
| tor8 | you even use it for "do while (1);" | 12:20.31 |
| Robin_Watts | I prefer while. | 12:20.35 |
| | but I use do ... while if it saves me a test. | 12:20.57 |
| tor8 | I never seem to end up in a position where do/while makes sense. guess our brains are wired differently. | 12:21.06 |
| Robin_Watts | and I used do { } while(1) purely cos the routine was do { ... } while (blah) when I last optimised it :) | 12:21.27 |
| | I prefer while (1) { ... } generally. I could change that back. | 12:21.51 |
| tor8 | the one thing neither of us do is for (;;) at least | 12:21.51 |
| Robin_Watts | tor8: yeah, I really dislike that. | 12:22.08 |
| tor8 | the symmetry is fine there, seeing as it's a duplicated loop for the bottom and top half of the triangle | 12:22.24 |
| paulgardiner | quickly removes for(;;) from the code he is writing | 12:23.15 |
| tor8 | I might've expressed that loop differently though, with a test for passing the mid point and only one while | 12:23.27 |
| Robin_Watts | Possibly I could get away with 16.16 fixed point if we dropped MAXNUM to 16384 | 12:23.40 |
| tor8 | MAXNUM is taken arbitrarily | 12:23.50 |
| Robin_Watts | tor8: I wanted to remove the midpoint processing from the loop. | 12:24.03 |
| | why test each time around if we have passed it or not? | 12:24.11 |
| tor8 | you test each time if you've passed y1 anyway... | 12:24.33 |
| Robin_Watts | And this way I don't need to call prepare_edge within the loop. | 12:24.44 |
| | tor8: right, but I can't avoid that test within the loop. | 12:25.13 |
| Robin_Watts | is hungry, needs lunch. bbiab unless you have anything else? | 12:26.37 |
| tor8 | not atm, just got back from lunch | 12:27.27 |
| Leukocyt | Hey Guys, is it just me or is the mu pdf git not responding? | 13:14.32 |
| Robin_Watts | seems OK to me. | 13:14.58 |
| Leukocyt | Hmm... I'ts taking really, really long to clone the git : ( | 13:15.10 |
| | I've tried it on several machines from various locations, but won't download : ( | 13:15.54 |
| Robin_Watts | Load average of 3 on casper, so that's not TOOO bad. | 13:16.26 |
| chrisl | It was slow earlier, but it seems okay now | 13:16.46 |
| Leukocyt | Hm.. looks pretty normal | 13:16.51 |
| Robin_Watts | Leukocyt: Are you seeing any progress at all? | 13:17.03 |
| Leukocyt | Robin_Watts: nothing at all | 13:17.18 |
| Robin_Watts | What command are you using? | 13:17.31 |
| Leukocyt | owh wait! it finally responded, maybe time to update my git client | 13:17.37 |
| | git clone http://mupdf.com/repos/mupdf.git | 13:17.39 |
| Robin_Watts | ok. | 13:18.13 |
| tor8 | Robin_Watts: trying to track down the text extraction segfault | 13:31.53 |
| | I can only find one place where spans are allocated, do you know if there are any more places? | 13:32.17 |
| Robin_Watts | no, there is only one. | 13:32.27 |
| | The problem is to do with for(span=... ; span; span = span->next) { ... } | 13:32.59 |
| tor8 | ah, I got it | 13:33.19 |
| | the problem is the loop down at the bottom | 13:33.27 |
| Robin_Watts | yeah. | 13:33.33 |
| tor8 | the file from bug 693845 (loveandpop_e) has some weird html extraction issues with the vertical text | 13:38.01 |
| | see page 2 for a simple isolated example | 13:38.13 |
| | Robin_Watts: patches on tor/master | 14:07.40 |
| Robin_Watts | apparently the timings from customer 530 may have been debug ones. | 14:08.05 |
| | so we might actually be as fast as before. will find out later. | 14:08.22 |
| tor8 | ah! | 14:08.32 |
| Robin_Watts | I have text coming out from svg. It's in the wrong font and upside down, but it's text :) | 14:16.29 |
| tor8 | cool! | 14:16.37 |
| | upside down text is the best text! ;) | 14:16.57 |
| Robin_Watts | tor8: Do we use UCDN yet ? | 14:20.03 |
| tor8 | we do now, with the last patch in the set | 14:20.22 |
| | for bidi class | 14:20.28 |
| Robin_Watts | In my fit of boredom this morning I discovered that we can shrink the ucd_records to 32bits (actually 30) with bitfields. | 14:20.46 |
| | I then realised there were only 698 such records, so the savings aren't great :) | 14:20.59 |
| tor8 | hehe. not worth going to all the pain of bitfields then :) | 14:21.26 |
| Robin_Watts | bitfields aren't pain in this instance, but I agree. | 14:22.21 |
| tor8 | I don't trust bitfields... | 14:22.42 |
| | and certainly not bitfields in combination with optimizing compilers | 14:22.52 |
| Robin_Watts | did you fix the lack of stdint.h ? | 14:23.41 |
| tor8 | yeah, by s/uint32_t/unsigned int/ | 14:23.53 |
| Robin_Watts | ah, cool. | 14:24.00 |
| | ok, so the linked list commit also makes a change to behaviour. | 14:25.44 |
| tor8 | yeah. we should maybe make mention of that. | 14:26.14 |
| Robin_Watts | Previously we merged lines if the 2 lines had the same region mask, and the second one only used 1 column. | 14:26.22 |
| tor8 | and also add back in the dehyphenation. I just realized I forgot that. | 14:26.26 |
| Robin_Watts | Now the stated behaviour is that we only merge lines if both lines are 1 column and the same column. | 14:26.59 |
| | but... the new test doesn't do that I think. | 14:27.10 |
| | line->first_span == line->last_span is "there is only 1 span" | 14:27.47 |
| | not, "there is only 1 column" | 14:27.53 |
| tor8 | there's a 1-to-1 mapping between spans and columns I thought | 14:28.13 |
| Robin_Watts | no. We can have several spans in the same column. | 14:28.30 |
| | In particular this can occur when we merge lines. | 14:28.41 |
| tor8 | d'oh! | 14:29.05 |
| | yeah. should fix that! | 14:29.13 |
| henrys | paulgardiner: so you have an exe that will print out the revision? | 14:29.24 |
| tor8 | maybe you should, you're more familiar with it... | 14:29.32 |
| Robin_Watts | Would it be possible to have this commit change the representation without changing the behaviour? | 14:29.54 |
| | and then do the behaviour as a separate thing? | 14:30.03 |
| paulgardiner | henrys: an app that displays the revision when a button is clicked. | 14:30.07 |
| tor8 | Robin_Watts: yeah. I just ran into some trouble mechanically transforming your old behaviour to the linked lists. | 14:30.26 |
| paulgardiner | ... pretty much the same thing. | 14:30.32 |
| tor8 | and started thinking about what it was actually supposed to do | 14:30.36 |
| Robin_Watts | tor8: never think! I thought once. It was horrible. | 14:30.54 |
| henrys | I'm wondering if it is a simple matter to plug in the simple example in gs/doc/api.htm? | 14:30.54 |
| | paulgardiner ^^^ | 14:31.04 |
| tor8 | you were running backwards through the lists, and I didn't want to add prev links unless absolutely required | 14:31.13 |
| henrys | paulgardiner: if that works - ship it! | 14:31.40 |
| Robin_Watts | tor8: I suspect I was running backwards as it makes merging easier. | 14:31.54 |
| | with arrays. | 14:31.59 |
| | tor8: I can take a look at this in a bit, if you want. | 14:32.51 |
| henrys | paulgardiner you can just hardwire constants for the inputs and not bother with input fields in an app. | 14:33.22 |
| tor8 | Robin_Watts: I'll break the commits apart so you have somewhere to go from | 14:34.33 |
| Robin_Watts | tor8: THanks. | 14:34.40 |
| | tor8: Are you happy with my version of your rasteriser? and the image format recognisers? | 14:35.22 |
| | (those are on robin master) | 14:35.44 |
| paulgardiner | henrys: Yeah that looks a good test. Only thing I'm not sure about is working out where a WinRT app is allowed to create files. The app's tempdir is one possibility, but then I'm not sure how to navifate to that from the desktop. Still, can't be hard | 14:35.44 |
| Robin_Watts | and the mudraw suffix changes (on svgwrite) | 14:36.31 |
| tor8 | Robin_Watts: not too fond of the loop constructs in the mesh rasterizer (they confuse my brain) | 14:36.54 |
| Robin_Watts | tor8: The do/while ? | 14:37.11 |
| tor8 | the suffix table on svgwrite LGTM | 14:37.13 |
| | the image document type LGTM | 14:37.42 |
| | the if followed by do/while | 14:38.14 |
| Robin_Watts | I use do/while rather than while, because we know the condition is true initially. | 14:38.18 |
| | hence I don't want the compiler to bother testing at the top of the loop. | 14:38.41 |
| tor8 | I know the reason, it's just annoying to read :) | 14:38.50 |
| Robin_Watts | I like the code that way because it's exactly what the code actually does. | 14:39.13 |
| | I dislike giving compilers an excuse to mess up :) | 14:39.30 |
| tor8 | it looks fine, but please zap the double space on "edge->x = vtop[0]..." | 14:40.19 |
| | I may let you have your do/while's but don't think I'm going to let you get away with vertical alignment ;) | 14:40.41 |
| Robin_Watts | will do. | 14:40.54 |
| tor8 | I have updated tor/master so you can bash on the linked list commit in isolation | 14:41.22 |
| Robin_Watts | Thanks. | 14:41.32 |
| tor8 | I pulled the bugfix down from the RTL patch so it shouldn't crash either | 14:41.55 |
| chrisl | paulgardiner: just one comment on the winrt stuff: building winrtsup.cpp should probably be done in base/winlib.mak or base/winplat.mak (if it's not fairly obvious how that should be done, I can do it once you commit to master) | 14:47.22 |
| paulgardiner | chrisl: Oh okay thanks. I'll have a look. | 14:48.12 |
| | henrys: what would make a good ps file to test? | 15:08.53 |
| henrys | examples/tiger.ps is our favorite | 15:09.13 |
| | sorry eps, it used to be a ps | 15:12.22 |
| | chrisl:I've always hated those macros | 15:13.36 |
| chrisl | henrys: yeh, time for them to go! | 15:14.06 |
| Robin_Watts | chrisl: I am confused by your commit message; why should unmacroising make things slower? | 15:14.37 |
| Robin_Watts | is too lazy to read the code. | 15:14.56 |
| chrisl | Robin_Watts: we have to save some state and retrieve it around the function calls | 15:15.16 |
| Robin_Watts | oh, I see, you turned them into function calls, you didn't just expand the macros. Gotcha. | 15:15.41 |
| henrys | when the code was written there really was the concern that inlines would be ignored, it is just a suggestion to the compiler. I don't think that is a concern these days. | 15:20.44 |
| chrisl | henrys: the testing I quoted was without the inline directive | 15:21.14 |
| henrys | oh wow - that is surprising | 15:27.00 |
| | either that or it means gcc optimization sucks and doesn't benefit from macros | 15:27.57 |
| chrisl | henrys: I suspect that two out the three functions were small enough to be automatically inlined even without the directive | 15:29.16 |
| paulgardiner | Hmm! gsapi calls are returning "success" but I have no pdf file. | 15:35.24 |
| Robin_Watts | bugger. I broke mupdf on the cluster. | 15:35.31 |
| | paulgardiner: What command are you calling? | 15:35.36 |
| paulgardiner | Not sure I am!! Just using the first example from the docs... Oh maybe ".setpdfwrite" ? | 15:37.18 |
| | arg0 is ps2pdf | 15:37.46 |
| Robin_Watts | paulgardiner: Confused then. In order to get a pdf page out, you need to give it a page worth of data in. | 15:38.30 |
| | for ps that's zero or more commands + "showpage". | 15:38.46 |
| henrys | we were going to try tiger.eps | 15:39.11 |
| | using example 1 from api.htm right? | 15:40.44 |
| Robin_Watts | henrys: Right, so I was expecting a set of command line args with "tiger.eps" in there. | 15:40.49 |
| henrys | Robin_Watts:the args are in example 1 | 15:41.57 |
| | we are replacing arg 9 (input.ps) with tiger.eps | 15:42.27 |
| Robin_Watts | henrys: yeah, I follow now, sorry. | 15:43.29 |
| kens | Night all | 16:07.43 |
| Robin_Watts | tor8: (For the logs) Fixed version of the reviews on robin master. | 18:02.07 |
| sebras | do I get it right if I believe that the new cff rasterizer in freetype only improves in the area of hinting..? | 18:48.00 |
| Robin_Watts | sebras: AIUI, yes. | 19:18.18 |
| sebras | Robin_Watts: AFAIK we never use hinting in mupdf so I guess this is not really helping us... | 19:20.15 |
| sinned2dth | Am I able to get some answers to questions about ghostscript here | 20:34.54 |
| sebras | sinned2dth: you are, though most developers are in the uk or the us so it might take some time before you get an answer. :) | 20:37.18 |
| | Forward 1 day (to 2013/05/04)>>> | |
IRC Logs