| | <<<Back 1 day (to 2012/10/21) | 2012/10/22 |
| sebras | morning mr. kens. | 08:06.51 |
| kens | Morning SIr Sebras :-) | 08:07.07 |
| sebras | kens: :) | 08:10.41 |
| Guest22871 | Hi, I've talked to you a few weeks back, and you told me to tell you if we're considering a license. Could you please give me the contact details of your colleague in charge with purchases? | 08:13.05 |
| kens | Sure, you need Scott Sackett, just a moment and I'll get his email address and contact details | 08:13.56 |
| | Guest22871 : | 08:14.37 |
| | Scott Sackett | 08:14.37 |
| | Vice President ~ Sales & Licensing | 08:14.37 |
| | Artifex Software | 08:14.37 |
| | (940) 482-7985 | 08:14.37 |
| | scott.sackett@artifex.com | 08:14.37 |
| Guest22871 | great, thank you! | 08:14.48 |
| kens | You're welcome. By the way that's a US telephone number in case it isn't obvious | 08:15.04 |
| kens | sets off to hunt the wild coffee bean | 08:15.59 |
| sebras | morning tor8. | 08:43.46 |
| tor8 | morning! | 08:47.41 |
| sebras | paulgardiner: morning paul! there are lots of messages for you in the logs | 09:22.25 |
| Robin_Watts | tor8: You suggested the other day that I should reuse the 'repair' code to do progressive rendering. | 09:25.14 |
| | (Morning all, btw) | 09:25.19 |
| tor8 | morning robin | 09:25.25 |
| Robin_Watts | I use the pdf_repair_object code to do the reading. | 09:25.41 |
| | The outer loop is slightly different though, so it's not entirely common. | 09:26.04 |
| tor8 | I was thinking more along the lines of making the repair mode a standard way of reading from the xref, that we can switch to if we get errors with the parsed xref | 09:32.30 |
| | and it seemed to me a lot of that would be common behaviour with how progressive mode has to work | 09:32.51 |
| Robin_Watts | I looked at that, and I couldn't easily see how to make it work. | 09:41.49 |
| tor8 | okay. it was just a thought. I haven't worked on that code in quite a while, so feel free to disregard it :) | 09:42.24 |
| | Robin_Watts: I've got an unrelated mystery to solve. Someone with a 13" mac book pro has been talking to applecare support in my name... using my artifex email. | 09:43.27 |
| Robin_Watts | No, I understand the thought behind it, and it may be that there is a way to do it. It would be be nice. | 09:44.02 |
| | tor8: wow. | 09:44.06 |
| | tor8: have you been experiencing blackouts recently? :) | 09:44.22 |
| tor8 | Robin_Watts: I don't have a 13" mac, and I never have. Last week I got an email about filling out a survey about my experience talking to a Maria... | 09:44.46 |
| | and this morning, UPS showed up with a tangerine designer leather sleeve for a 13" mac book pro... | 09:45.14 |
| Robin_Watts | eek. | 09:46.25 |
| | The first one sounds like apple having a database problem. | 09:46.47 |
| | The second one sounds more sinister. | 09:46.54 |
| paulgardiner | tor8: what about credit card history? | 09:46.55 |
| tor8 | yeah, so I ignored that email. | 09:47.00 |
| | but now with the really hugely expensive sleeve sitting in a box on the floor, I'm inclined to start investigating | 09:47.23 |
| | paulgardiner: nothing there I can't account for going back three months. I just checked. | 09:47.45 |
| | I looked up the support number on their web site so I have the serial number of the computer in question | 09:47.58 |
| paulgardiner | That's a relief | 09:48.09 |
| tor8 | gonna give them a ring after lunch | 09:48.11 |
| | ask them what the hell is going on | 09:48.18 |
| miha | is there a way to speed up mupdf (android)... lower resolution perhaps? http://code.google.com/p/ebookdroid/wiki/Summary?tm=6 seems to use mupdf faster | 10:05.02 |
| | thread priority? | 10:05.31 |
| Robin_Watts | No idea. | 10:15.38 |
| | I am not familiar with that particular package, and hence have no idea what it's doing. | 10:16.04 |
| | If it's for e-books it may be rendering in greyscale rather than colour? | 10:16.25 |
| | but there is no magic bullet for making mupdf render faster. | 10:17.01 |
| sebras | paulgardiner: um... not wanting to harrass you -- just looking for confirmation it entered the todo-list -- you saw my droid patches, yes..? | 10:28.36 |
| paulgardiner | sebras: yep. Just looking now. You add the app name and version onto the title. What is the title typically before doing that? | 10:30.06 |
| sebras | it's what the picker_title string attribute is set to... | 10:30.28 |
| | so on screen I see "MuPDF" and after a second or so it's "MuPDF 1.1" | 10:30.51 |
| | ideally we should base this of git describe being run in build.xml, but I didn't bother to puzzle that together (yet). | 10:31.35 |
| paulgardiner | Sorry, I may be confused. The title is set to title+appname+version. So is title initially NULL? | 10:31.42 |
| | Ignore me | 10:32.31 |
| sebras | I was about to write the same. :) | 10:32.43 |
| paulgardiner | That's the format isn't it. :-) | 10:32.43 |
| sebras | yes. | 10:32.48 |
| | and it's created in onCreate(). | 10:33.31 |
| malc_ | tor8: hello, mupdf fails to chew on this years IOCCC silver award winner's PDF output | 10:50.34 |
| Robin_Watts | malc_: yeah, sebras reported that to us on friday, I think. | 10:51.24 |
| | Did you see the fix for the previous thing you reported? | 10:51.42 |
| malc_ | Robin_Watts: aye (if by previous you mean double free) | 10:52.08 |
| Robin_Watts | yeah. | 10:52.15 |
| malc_ | thanks | 10:52.45 |
| sebras | malc_: the reason is that the PDF object numbers are intertwined with the C-comments in the file. | 10:53.42 |
| | malc_: I fixed the IOCCC submission instead of fixing mupdf and made it succeed. | 10:54.09 |
| | malc_: there's no point really to coax mupdf to handle that file I think. :) | 10:54.57 |
| malc_ | sebras: well, there is - pride, xpdf chews it, ghostscript does too, even acroread (allegedly).. the shame of not ebing up to scratch would overwhelm tor8 (eventually) | 10:56.36 |
| sebras | malc_: I was intrigued enough to test it, so you never know... | 10:58.25 |
| malc_ | sebras: is your patch to hamano.c available somewhere? | 10:59.00 |
| sebras | malc_: no. it was in /tmp. | 10:59.15 |
| Robin_Watts | sebras: So can you post a fragment of the offending file? | 11:00.13 |
| paulgardiner | sebras: I understand your fix, but do you know how mChildViews.get(mCurrent) manages to return null? | 11:02.20 |
| malc_ | Robin_Watts: http://www.ioccc.org/2012/hamano/hint.html http://www.ioccc.org/2012/2012.tar.bz2 | 11:03.23 |
| paulgardiner | I think I see it: there may be a post(this) outstanding when setAdapter is called. | 11:03.58 |
| Robin_Watts | malc_: I was hoping for the relavent section of a file that fails, rather than the source for the generating code. | 11:04.48 |
| paulgardiner | sebras: If that is the case that leads to the null exception, I'd imagine you don't need to recall post(this) in the null case - just guard the call to postSettle(v)... Of course you may have tried that and already established that doesn't work. :-) | 11:06.10 |
| malc_ | Robin_Watts: http://www.boblycat.org/~malc/hint.pdf.bz2 | 11:06.14 |
| sebras | Robin_Watts: malc_: http://pastebin.com/G1TcPR2z | 11:06.37 |
| Robin_Watts | Ah. It produces broken PDF? | 11:07.19 |
| | and relies on the repair code to fix it ? | 11:07.34 |
| sebras | Robin_Watts: well... it's a pdf and a c-file at the same time. | 11:07.36 |
| | Robin_Watts: I'm not sure. | 11:07.45 |
| malc_ | it's not really broken | 11:07.48 |
| sebras | we misinterpret the <> in the #include, why that is I don't know. | 11:08.04 |
| malc_ | PDF reference 1.3 is pretty explicit about PDF version marker being in the first K of input | 11:08.09 |
| | not necesarily first line | 11:08.16 |
| sebras | I haven't checked the consistency of the file itself. | 11:08.41 |
| | i.e. I have no clue if it conforms to spec. | 11:08.51 |
| | paulgardiner: well. onLayout() would render the stuff and populate mChildViews.get(mCurrent), no..? but this is called _after_ run() in my case. | 11:09.41 |
| Robin_Watts | OK. I'm finding it really hard to think I care about this :) | 11:09.55 |
| sebras | Robin_Watts: I think I mentioned something along those lines... | 11:10.26 |
| paulgardiner | sebras: yes, that is what might happen if there was a post(this) outstanding when setAdapter is called. | 11:11.25 |
| | sebras: but the layout should issue its own post, negating the need to do so when v == null in the run call. | 11:12.26 |
| | ... I think. | 11:12.40 |
| sebras | paulgardiner: it may very well be the case that I don't understand the app architecture enough to have made a good patch. | 11:13.50 |
| | this is why I wanted a review. :) | 11:13.57 |
| paulgardiner | I wouldn't say it isn't a good patch, and I'm struggling to understand the architecture myself even though I coded most of it. | 11:15.02 |
| sebras | paulgardiner: what I saw was that run() was called with mUserInteracting == false and mChildView.get(mCurrent) == null. | 11:15.47 |
| | this is in itself not a problem until postSettle() executed onSettle() which in turn dereferenced v. | 11:16.36 |
| | I never established from where the setAdapter() call originates. | 11:17.05 |
| paulgardiner | Yes, and I now think I see the scenario that causes this. Is it only if going out of the activity and back in? | 11:17.29 |
| sebras | no. | 11:17.41 |
| paulgardiner | Ah. | 11:17.48 |
| sebras | this is hammering on the progressbar. | 11:17.54 |
| | actually i never saw mUderInteracting being set to true! | 11:18.13 |
| | this appears only to be set by onTouchEvent(), but I never ended up there. | 11:18.56 |
| paulgardiner | So, without your patch, do we have two types of crash caused by hammering on the progress bar? We had one before that was to do with taking too long to respond to UI. | 11:19.58 |
| sebras | we might. I'm not sure. | 11:20.30 |
| | with my patch I can no longer reproduce a _crash_. | 11:20.37 |
| | after a few seconds of the UI freezing android pops up a dialog asking if I want to force close or wait. | 11:20.56 |
| paulgardiner | Right! and that I think I can fix too. | 11:21.18 |
| sebras | if I choose to wait, then mupdf will resolve the situation eventually after having rendered several pages. | 11:21.19 |
| | after that this the app is resposive in the normal way. | 11:21.37 |
| paulgardiner | So, without the patch, you get the pop up, but if you wait it crashes? Or do you not even get the box? | 11:23.12 |
| | dialog | 11:23.30 |
| sebras | no dialogbox without the patch, just a crash. | 11:23.43 |
| | and that is due to the nullpointerexception. | 11:23.49 |
| | so I'm beginning to think that the nullpointer was the cause all along. | 11:24.03 |
| | and that I was misinterpreting the logcat. | 11:24.11 |
| paulgardiner | Well, we shouldn't be stalling the UI, and I know what in the code is doing it, but in any case protecting agains the null exception is wise. | 11:25.04 |
| sebras | yes, why is the post(this) not necessary? | 11:25.33 |
| paulgardiner | Have you tried a version that just protects agains the bad call, but without issuing post(this) in the null case? | 11:25.39 |
| sebras | will onLayout call post(this) later? | 11:25.41 |
| | no. | 11:25.49 |
| paulgardiner | That's what I suspect. That onLayout will call it. | 11:26.10 |
| sebras | tests | 11:26.35 |
| miha | so you do android? :) | 11:27.37 |
| sebras | miha: mupdf has been ported to android by Robin_Watts and paulgardiner, yes. | 11:28.01 |
| | miha: the .apk is available on mupdf.com | 11:28.13 |
| Robin_Watts | (and by many other people - pretty much every PDF viewer on the Google Play store is actually based on mupdf) | 11:28.43 |
| miha | sebras: i know. source too. staring at it right now. why is it so terribyl slow for some pdfs? :D | 11:28.50 |
| Robin_Watts | miha: Depends on the PDF. Can't comment without seeing it. | 11:29.15 |
| sebras | miha: if you can provide the .pdf in a bugreport we' | 11:29.31 |
| | ll certainly take a look at it. | 11:29.36 |
| miha | i'm not sure if i'm allowed to :) | 11:29.52 |
| Robin_Watts | Improvements are being made all the time (shadings were particularly memory intensive until a couple of weeks ago, for example) | 11:29.55 |
| | miha: Well, we can mark attachments as private so no one outside Artifex can see them. | 11:30.15 |
| sebras | paulgardiner: looks like that works too. | 11:31.31 |
| | paulgardiner: waiting for the final page to render. | 11:31.58 |
| miha | will get back to you guys later, when i get a copy i can share :) | 11:32.20 |
| | thx | 11:32.31 |
| sebras | paulgardiner: and there we go. so, yes it works without calling post(this). | 11:32.32 |
| paulgardiner | Great. I'm so pleased to have all the known crashes fixed. Brilliant | 11:32.33 |
| Robin_Watts | miha: np. thanks. | 11:32.38 |
| sebras | paulgardiner: ok, so you'll update my patch before it is merged? | 11:33.25 |
| | or should I? | 11:33.32 |
| paulgardiner | There's something that worries me a little about e40ab93. adapter.add is called on a background thread. Do we know that's ok? Could use AsyncTask there and then the adapter.add would be called on the UI thread in postBackground | 11:37.02 |
| | sebras: I'd recommend updating the patch if its not too much hassle. | 11:37.44 |
| sebras | paulgardiner: np. | 11:38.24 |
| | paulgardiner: about e40ab93: no I have no idea whether ArrayAdapter is threadsafe now that you mention it. | 11:39.01 |
| | paulgardiner: patch fixed. and e40ab93 is now on top, so you can easily skip it if you want to merge my patches as is. | 11:44.36 |
| Guest22981 | Hi, guys! in the Android app, if you zoom in the document and start scrolling around, the memory will start to add up, and eventually, it will crash with an outofmemory exception. It crashes even faster if you put 2 pages on a screen, for example. Any clues on how this can be prevented? | 11:49.25 |
| sebras | Guest22981: this is for any document, right? | 11:51.32 |
| paulgardiner | sebras: great thanks. I can't actually push them to the main repo though. | 11:54.01 |
| sebras | paulgardiner: I know. but once you are convinced the patches are good I'm sure you won't stop harrassing Robin_Watts until they are merged. ;) | 11:54.41 |
| | so I'm merging by proxy. | 11:54.54 |
| Robin_Watts | sebras: I'll push them as soon as paulgardiner is happy with them. | 11:55.02 |
| Guest22981 | Yes, both documents heavy on greaphics, and text only. | 11:55.10 |
| sebras | Robin_Watts: no worries. :) | 11:55.30 |
| Robin_Watts | Guest22981: We have not seen that in our testing. | 11:55.38 |
| | (well, we've seen problems where if you scroll between pages fast you can cause problems) | 11:56.03 |
| | but not if you step between pages at a reasonable speed. | 11:56.27 |
| paulgardiner | Robin_Watts: all are fine except the last to do with updating the file list upon download directory changes. | 11:56.40 |
| Robin_Watts | How are you putting 2 pages on a screen? | 11:56.44 |
| sebras | Guest22981: when you say you are scrolling around, do you ever let go with you finger so that mupdf is allowed to render at a higher resolution? | 11:56.44 |
| Guest22981 | I know, you need to play with the document a lot before it crashes. The memory footprint will increase, and decrease, but eventually one of thwe spikes will go over the budget and crash the whole thing. | 11:56.58 |
| paulgardiner | Robin_Watts: the last might need to be converted to using asynctask unless we find that the adapter is thread safe | 11:57.18 |
| Guest22981 | I put 2 pagea on a screen by loading them side by side in a linear layout | 11:57.21 |
| Robin_Watts | Guest22981: Ah, so you're modifying our code? | 11:57.42 |
| Guest22981 | yes, I let it do its job in rendering. I have noticed that with a modified version, but then I took the apk from googlecode, and it takes a bit more time to crash it. | 11:58.27 |
| Robin_Watts | sebras, paulgardiner: pushed | 11:59.27 |
| paulgardiner | great thanks | 11:59.35 |
| Robin_Watts | Guest22981: What android device | 12:00.06 |
| miha | btw this ndk-build .. can it build for intel processors too? or just arm? | 12:00.08 |
| Robin_Watts | ? | 12:00.08 |
| sebras | Robin_Watts: :) | 12:00.09 |
| | paulgardiner: http://stackoverflow.com/questions/6244330/is-arrayadapter-thread-safe-in-android-if-not-what-can-i-do-to-make-it-thread | 12:00.20 |
| Robin_Watts | miha: We've only tested it on arm. | 12:00.23 |
| Guest22981 | Galaxy Tab 10.1 | 12:00.30 |
| Robin_Watts | miha: but there is no ARM specific code. | 12:00.33 |
| | You say "go over the budget"... what budget is that ? | 12:00.59 |
| Guest22981 | I mean, it goes over like 64 MB of allocated memory, then it throws the exception | 12:01.26 |
| sebras | Guest22981: you wrote "but then I took the apk from googlecode, and it takes a bit more time to crash it." does this mean that you managed to crash our pre-built app? | 12:01.57 |
| Guest22981 | yes | 12:02.07 |
| Robin_Watts | Guest22981: So is there a magic memory use level at which android kills apps? | 12:02.33 |
| Guest22981 | yes, that's what the guys over at Google say | 12:03.04 |
| Robin_Watts | Well, that's interesting. | 12:03.19 |
| paulgardiner | sebras: that seems to suggest most things should be done on the main thread. Is that your reading? | 12:03.55 |
| sebras | paulgardiner: haven't come that far yet. | 12:04.25 |
| Robin_Watts | Guest22981: Well, we have a mechanism within mupdf to limit the store size. | 12:05.04 |
| miha | Robin_Watts: now i checked out from git, but it doesnt compile (make on top level dir) | 12:05.27 |
| Robin_Watts | But even if we set the store size to zero, it would be possible to overrun any given limit in 'transient' data, due to the size of the display list created. | 12:06.01 |
| paulgardiner | aagghh! Sorry sebras. Your code isn't using a background thread. Doh! | 12:06.24 |
| Robin_Watts | The only way to avoid that would be to have a way to detect the approaching memory overflow and to drop back to non-display list based behaviour. | 12:06.55 |
| miha | may i paste? :) | 12:07.54 |
| Robin_Watts | Guest22981: That's perfectly possible to do in the current code; you just need to provide your own allocator functions to mupdf and keep track of it. | 12:08.02 |
| sebras | miha: pastebin.com if it is long. | 12:08.05 |
| miha | 3 lines | 12:08.08 |
| Robin_Watts | paste away. | 12:08.13 |
| miha | fitz/image_jpx.c:95: error: âCLRSPC_SRGBâ undeclared (first use in this function) | 12:08.15 |
| sebras | miha: compiles well here..!? | 12:08.17 |
| miha | fitz/image_jpx.c:96: error: âCLRSPC_SYCCâ undeclared (first use in this function) | 12:08.18 |
| | make: *** [build/debug/image_jpx.o] Error 1 | 12:08.21 |
| Robin_Watts | miha: OK. so you were doing a top level make to make the generated stuff? | 12:08.41 |
| miha | Robin_Watts: yes | 12:08.47 |
| sebras | miha: you did run git submodule update --init after cloning, right? | 12:08.49 |
| Robin_Watts | Well, I think you've come far enough already. | 12:08.55 |
| miha | sebras: no :$ | 12:08.56 |
| paulgardiner | sebras: so observer.startWatching will lead to one initial call to post and then others each time the directory changes? | 12:09.26 |
| Robin_Watts | I suspect that you can ignore that error and continue - but you will run into problems on the ndk-build stage later. | 12:09.32 |
| | As sebras says, you should clear your thirdparty dir, and then do git submodule --init. | 12:10.02 |
| | Probably I need to update the android instructions with that particular nugget. | 12:10.19 |
| sebras | paulgardiner: no, no initial call, this is ny mHanlder.post(mUpdateFiles) is there. | 12:10.33 |
| miha | Robin_Watts: not sure, ndk-build says jni/../../fitz/dev_text.c:564: error: 'FT_STYLE_FLAG_ITALIC' undeclared (first use in this function) | 12:10.34 |
| | make: *** [obj/local/armeabi/objs-debug/mupdfcore/__/__/fitz/dev_text.o] Error 1 | 12:10.37 |
| sebras | paulgardiner: ny -> why | 12:10.39 |
| | Robin_Watts: already done. ;) | 12:10.50 |
| Robin_Watts | miha: Right. You've got old versions of the thirdparty stuff. | 12:11.05 |
| miha | Robin_Watts: one from your website | 12:11.15 |
| Robin_Watts | sebras: Ah! Thanks. | 12:11.25 |
| | miha: We recently changed so that you should get the thirdparty stuff from git, NOT from the website. | 12:11.49 |
| | But I forgot to update the android instructions to that effect. | 12:12.04 |
| paulgardiner | sebras: right. I was specifically looking for that, and somehow missed it. | 12:12.04 |
| sebras | Guest22981: I'm still intrigued by how you manage to reproduce this. can you explain more in detail what you are doing when you are scrolling around? | 12:12.08 |
| Robin_Watts | Sebras has updated the instructions though, and they were pushed to the repo a few minutes ago. | 12:12.21 |
| paulgardiner | sebras: that really nice, and absolutely fine as far as I can see. | 12:12.44 |
| sebras | paulgardiner: ok, so you are convinced that it is threadsafe? | 12:12.59 |
| paulgardiner | Robin_Watts: My misgivings about the last commit were unfounded. That can be pusshed too. | 12:13.08 |
| Robin_Watts | will do. | 12:13.15 |
| sebras | paulgardiner: all these intents and activites and framework stuff is all new to me so I'm treading lightly. | 12:13.20 |
| paulgardiner | sebras: post will cause the run to be invoked on the UI thread. | 12:13.31 |
| sebras | paulgardiner: ok, ok. then I'm safe. even according to the article. :) | 12:13.49 |
| paulgardiner | Yep | 12:13.56 |
| Robin_Watts | pushed. | 12:13.58 |
| sebras | Robin_Watts: thanks a bunch. | 12:14.04 |
| paulgardiner | And I was just confusing myself. | 12:14.08 |
| Robin_Watts | sebras: Thank you for fixing stuff! | 12:14.14 |
| sebras | this improves my ohloh rating. :) | 12:14.25 |
| paulgardiner | most definitely. | 12:14.47 |
| Robin_Watts | sebras: Ha! | 12:14.54 |
| Guest22981 | So, I am opening a one-page PDF document, zoom in fully, then start scrolling around while watching the "Allocated heap" size growing, and eventually crashing the app. | 12:14.59 |
| sebras | Guest22981: where do you keep track of the allocated heap size? | 12:15.21 |
| Robin_Watts | Guest22981: Well, it's possible we are leaking somewhere (that would be bad). | 12:15.42 |
| sebras | Guest22981: also is this a continuous scroll, i.e. do you ever lift your finger or just continue to scroll around without lifting it? | 12:15.50 |
| Guest22981 | I see it in Eclipse DDMS, and the scroll is not continuous: I do mostly flings, and let it render. | 12:16.33 |
| sebras | Guest22981: but all are within a single page? | 12:16.52 |
| Guest22981 | yes, the document has only one page. | 12:17.16 |
| | I'm guessing that the bitmaps created in AddHQ() don't get a chance to be cleaned up, and stack up until the memory runs out | 12:19.32 |
| paulgardiner | Guest22981: that was a problem at one stage, but I believe I fised that in 9e609e1d | 12:25.01 |
| sebras | Guest22981: I'm having a hard time reproducing this. | 12:25.06 |
| paulgardiner | s/fised/fixed | 12:25.11 |
| Robin_Watts | The apk probably hasn't been rebuilt since. | 12:25.22 |
| | Does anyone have a recently apk online that Guest22981 could try? | 12:25.36 |
| paulgardiner | Robin_Watts: oh, that's possible | 12:25.38 |
| Guest22981 | that would be nice | 12:26.23 |
| miha | so did android src to jni interface change from 1.0rc ? :) | 12:27.38 |
| paulgardiner | http://intranet.glidos.net/~paul/MuPDF20120918b.apk I think that's the one I posted just after fixing that. | 12:27.45 |
| Robin_Watts | miha: yes. | 12:27.59 |
| paulgardiner | Or http://intranet.glidos.net/~paul/MuPDF20120918.apk. Not sure what changed between those two. | 12:28.25 |
| miha | Robin_Watts: what is a good way to do this.. i'd like to keep my modification to ...Activity.java and ReaderView.java :) | 12:29.00 |
| | just asking :p | 12:29.09 |
| Robin_Watts | miha: Are you working from git? | 12:29.16 |
| | If so, stash, then pull then stash apply. | 12:29.38 |
| miha | i do use git, but i'm kind of noob at it :p | 12:29.54 |
| Robin_Watts | If not, then diff your current source with the source you were based on. | 12:29.56 |
| miha | diff i can do | 12:30.01 |
| Robin_Watts | then update to the new version and apply your diffs - if you can. | 12:30.27 |
| miha | :D | 12:30.32 |
| Robin_Watts | Guest22981: I guess we should ask how you are using MuPDF... | 12:30.48 |
| | Presumably you're building your own android app with it in. | 12:31.06 |
| | As I'm sure you know MuPDF is released under both the GNU GPL license and the Artifex commercial license. | 12:31.33 |
| | Assuming you are happy to comply with the terms of the GNU GPL, then you can use MuPDF with no charge. This includes, but is not limited to, releasing all the sources for your app (including both any modifications to MuPDF and any code that you link with MuPDF). | 12:32.44 |
| | For some app authors this is a real problem, as it means that people have to give their source away. | 12:34.07 |
| | If this is a problem for you, then we can offer you a license with none of those restrictions, but we charge for it. | 12:34.28 |
| Guest22981 | yes, I know, I asked you earlier for the sales department contact details :) | 12:34.35 |
| Robin_Watts | Ah, sorry! | 12:34.42 |
| miha | Robin_Watts: is there any public info on pricing? | 12:35.43 |
| Robin_Watts | miha: No. Essentially every license deal we do is tailored to individual customers, so to quote prices would either put people off, or set their expectations incorrectly. | 12:36.27 |
| Guest22981 | no problem! I stumbled upon this issue, ans it seems that it's my bad for it: I am using a push from Sep 3, and the problem doesn't seem to exist in the apk you've sent me - that's a relief! | 12:36.28 |
| sebras | Guest22981: not easy to know that Guest22871 and Guest22981 are the same person. :) | 12:36.34 |
| Robin_Watts | Guest22981: Fab, thanks for that. | 12:36.51 |
| | I have an open bug I can probably close then. | 12:37.07 |
| Guest22981 | Yes, I sometimes customize my nickname, sometimes not. | 12:37.42 |
| miha | Robin_Watts: i see, thank you | 12:38.45 |
| Guest22981 | I also have another question - is it possible (or efficient) to pass an inputstream to the native openFile method, instead of the filename? I haven't found anything on that. | 12:39.17 |
| miha | btw current version renders that pdf faster, but still i see loading icon too much | 12:39.41 |
| Robin_Watts | Guest22981: OK. Here is my standard spiel :) | 12:40.38 |
| | MuPDF is a set of libraries for handling PDF/XPS/other file formats. We can load/save/render such files. | 12:41.09 |
| | Using these libraries we have various thin wrappers of code that produce various different tools/viewers. | 12:41.43 |
| | The android viewer is one such thin wrapper. | 12:42.04 |
| | (while there is android specific smartness in the android viewer, all the heavy PDF lifting is done within the core). | 12:42.34 |
| | The inner core of MuPDF is certainly capable of reading PDFs from a stream rather than from a file (indeed, we have customers that implement their own custom DRM schemes using this). | 12:43.32 |
| Guest22981 | yes, that would be the case here, too | 12:43.55 |
| Robin_Watts | The core of MuPDF is in C, and the C interface is our defined one. | 12:44.21 |
| | We have exposed an interface across JNI to allow java code to call the C functions. | 12:44.43 |
| | That's not a defined interface as such - it's just enough to allow us to write the wrapper, and we reserve the rights to change it at any time. | 12:45.09 |
| | so, as such, there is no support in there at the moment for passing an InputStream across. | 12:45.36 |
| | but that could probably be added as required without too much of a problem. | 12:45.56 |
| | Bear in mind though that PDFs are intrinsicly random access. In order to read a PDF we need to be able to seek around within it. | 12:46.34 |
| | Guest22981: Does that answer your question? | 12:46.44 |
| Guest22981 | yes, thank you. | 12:48.58 |
| | so, if I'd give the stream to the native code, I;d need to somehow rebuild the document in the memory, so that the entire data structure could then be randomly accessed from within the code, am I right? | 12:50.13 |
| Robin_Watts | Or the stream would itself need to be seekable. | 12:50.44 |
| Guest22981 | I See | 12:50.58 |
| Robin_Watts | (I am not familiar with the semantics of java streams offhand) | 12:51.27 |
| Robin_Watts | goes to lunch. back in a bit. | 12:52.05 |
| norbertj | Robin_Watts you here? | 13:29.37 |
| | hello kens | 13:32.09 |
| kens | Hi norbertj | 13:32.18 |
| norbertj | can you make the attachment (3rd) on BUG 693385 private? | 13:32.37 |
| kens | Yes, I'll do it right now | 13:32.44 |
| norbertj | thanks | 13:32.52 |
| Robin_Watts | norbertj: back, sorry, was at lunch. | 13:33.02 |
| | but it looks like kens has sorted it for you. | 13:33.05 |
| kens | DOne | 13:33.15 |
| | attachment is labelled as 'complete file (9 pages)' | 13:33.36 |
| norbertj | kens yes | 13:35.48 |
| kens | OK should be private now. | 13:36.05 |
| | Its red for me but of course I can still access it. | 13:36.16 |
| norbertj | me too | 13:36.50 |
| henrys | kens:are we up to date support-wise? It looks that way. | 15:26.13 |
| | Robin_Watts:did you disable henrysx6 and macpro - I do remember the cups problem on henrysx6 but we fixed that. | 15:34.55 |
| Robin_Watts | I disabled henrysx6 | 15:35.23 |
| | I can reenable it. | 15:35.29 |
| henrys | maybe marcos identified something wrong with macpro - I guess we'll wait for him. | 15:36.35 |
| | quite a queue today. | 15:36.55 |
| Robin_Watts | blame sebras :) | 15:38.04 |
| sebras | Robin_Watts: hey! :) | 15:38.32 |
| henrys | with more contributors like sebras we could get rid of a few employees ;-) | 15:39.24 |
| miha | Robin_Watts: updated to current version of mupdf android. most pages it opens much better now. still it takes a while for some | 15:41.00 |
| Robin_Watts | miha: If you can share an example of one that takes longer than you'd like, we can try to figure out why. | 15:41.31 |
| miha | will do | 15:42.20 |
| Guest22981 | I'm back with a new question regarding the outofmemory issue I'm facing: it seems that it only appears when I scroll and don't let it render before scrolling someplace else. So, the memory fills up. But, if I let it render, then scroll, it recovers. I have tried to call removeHq() before AddHq(), to no avail. I got to the conclusion that I must somehow stop the execution of the function fz_run_display_list when scrolling away | 15:46.15 |
| sebras | henrys: :) | 15:46.37 |
| Guest22981 | I see there fz_free_display_list - is it appropriate for what I need? | 15:46.37 |
| Robin_Watts | Guest22981: Urm... | 15:48.30 |
| | That sounds a lot like the problem we were having with our android viewer; paulgardiner can correct me here if (when) I go wrong... | 15:49.15 |
| | when we scroll, we first do a 'fuzzy' redraw where we scale up a background image. | 15:49.39 |
| Guest22981 | yep | 15:49.50 |
| Robin_Watts | then we queue a high quality redraw on an async task. | 15:50.09 |
| | when that completes, we draw the high quality redraw, and all is good with the world. | 15:50.26 |
| | The problem is that if we keep scrolling repeatedly, we keep queuing more and more background tasks. | 15:50.56 |
| Guest22981 | exactly | 15:51.05 |
| miha | Robin_Watts: is there a way to specify dpi to render? | 15:51.23 |
| Guest22981 | I thought that Add/ Remove Hq took care of that, by stopping bg redraws i any | 15:51.27 |
| Robin_Watts | Now, I'm trying to remember the next bit correctly... | 15:51.51 |
| paulgardiner | But we do cancel them, and since the commit I mentioned we don't allocate bitmaps until committed to the render | 15:52.03 |
| | Guest22981: is this vanilla master? | 15:53.00 |
| Robin_Watts | thanks paulgardiner. So we used to make a bitmap when we queued the AsyncTask. Hence if we had lots of Async tasks queued we had lots of bitmap memory used. | 15:53.14 |
| paulgardiner | Yes | 15:53.30 |
| Robin_Watts | But paul changed it so we only allocate the bitmaps when the time comes to really come to do the render. | 15:53.44 |
| | This means we don't tie up lots of memory for no reason any more. | 15:53.58 |
| Guest22981 | no, it's the modified project, where I updated the sources with the ones I pulled several hours ago. | 15:54.04 |
| Robin_Watts | We can still hit a problem where we can fail to queue an async task due to the task list being full, but that will just result in everything freezing for a while until the queue empties. | 15:54.50 |
| | Guest22981: Now, if I'm following what you said correctly, you've changed so you can have 2 pages up at a time right? | 15:55.24 |
| Guest22981 | yes | 15:55.27 |
| Robin_Watts | So presumably you must have cannibalised our classes a bit. | 15:55.33 |
| | Are you still queueing bitmaps at the same time you queue AsyncTasks ? | 15:55.57 |
| Guest22981 | yeah, sort of :) I saw that your sample works great, and am trying to find the bit where you fixed that problem | 15:56.09 |
| paulgardiner | I posted the commit sha earlier | 15:56.31 |
| Robin_Watts | http://git.ghostscript.com/?p=mupdf.git;a=commitdiff;h=9e609e1dcf6a1dac9195a4cfecac2a573ba42433 <- That one paulgardiner ? | 15:57.27 |
| paulgardiner | That's it | 15:57.39 |
| | This will all have to change again for partial update. | 15:57.53 |
| | We still allocate loads of bitmaps, but with that commit the system is always able to garbage collect all but the ones currently used (about 6 of them) | 15:58.51 |
| marcosw | just a quick update re. the cluster. I added a large set of files to the tests_private repository which caused problems as the nodes tried fetching the files, would time out, and then retry. I've hacked around this but independently now all of the nodes at miles' office have gone offline. We are having weather in the bay area so he may have had a power failure (it's supposed to clear in time for the giants game tonight). | 16:01.45 |
| paulgardiner | BTW, even with that commit, frantic page changing could cause a crash, but a very resent commit by sebras has fixed that. | 16:02.18 |
| Guest22981 | it;s strange that "git log" doesn't show me that commit - a pull tells me that I'm up to date, and the last commit is commit c2a526b73e6654b99c66747a379a9218ab8683f4 Author: Sebastian Rasmussen <sebras@gmail.com> Date: Sun Oct 21 13:09:13 2012 +0200 | 16:02.18 |
| Robin_Watts | Guest22981: I suspect you're not looking far enough back in history. | 16:02.48 |
| | That was 18/19th September. | 16:02.57 |
| Guest22981 | aw, so, I would have it already, then | 16:03.13 |
| sebras | Guest22981: you are looking for commit 9e609e1 | 16:03.57 |
| | Guest22981: and yes you ought to have it already. :) | 16:04.11 |
| ray_laptop | morning, all | 16:05.09 |
| Robin_Watts | Morning ray_laptop | 16:05.15 |
| henrys | hi ray_laptop | 16:05.26 |
| Robin_Watts | I had a stare at 693166 this morning. | 16:05.27 |
| ray_laptop | we may have to change this channel to "mupdf_and_ghostscript" | 16:05.41 |
| miha | Robin_Watts: is there a way to specify dpi to render? or something else to gain speed? :) | 16:05.41 |
| Guest22981 | well, I have to go now, and I'll search tomorrow for the part where you don't alloc the bitmaps until needed, and fix my project using that | 16:05.45 |
| Robin_Watts | based on your comments on irc yesterday are you satisfied that the bug is fixed, or are you still looking for some change? | 16:06.17 |
| ray_laptop | Robin_Watts: I didn't post my other discoveries in the bug, but did you see my follow ups in the IRC logs ? | 16:06.30 |
| Robin_Watts | miha: Whenever you render, you specify the transformation to use. | 16:06.46 |
| | ray_laptop: I pasted your irc comments into the bug. | 16:06.59 |
| ray_laptop | Robin_Watts: Thanks -- I hadn't seen that yet | 16:07.12 |
| Guest22981 | thank you for your pacience, and have a great time! | 16:07.15 |
| Robin_Watts | I have a tiny patch here that says "don't use high-level images if we are scaling up by more than a factor of 32 on any axis". | 16:07.44 |
| | Which seems a reasonable fix to me. | 16:07.51 |
| ray_laptop | Robin_Watts: The question is: Is there something we can do to reduce the amount of processing when interrpolating post-clist ? | 16:08.02 |
| Robin_Watts | ray_laptop: No. | 16:08.09 |
| | I already do my very best to keep the amount of post-clist work down to a minimum. | 16:08.37 |
| | but as you add more bands you add more vertical 'breaks' in the images. | 16:08.57 |
| | and for each 'break' in the image we have to calculate a certain number of interpolated rows. | 16:09.18 |
| | The number of extra interpolated rows we have to calculate goes up the more the scale factor goes up. | 16:09.57 |
| ray_laptop | Robin_Watts: it seems that this goes beyond the 'support' lines, but do we _really_ need 8 support lines ? | 16:09.57 |
| Robin_Watts | We calculate the 'source area' of the image that can be seen once transformed. | 16:10.27 |
| | and the source area is of course integer valued. | 16:10.42 |
| miha | Robin_Watts: i added debug messages tu MUPDFCore.java drawPage .. and for zoom HQ image it says 10-22 18:11:01.062: D/MuPDFCore(14639): Drawing page 21 pageW1056 pageH 1491 patch X 267 patch Y 316 patchW 480 patchH 762 | 16:10.56 |
| | 10-22 18:11:18.867: D/MuPDFCore(14639): Page drawn: 17808 ms | 16:11.00 |
| ray_laptop | Robin_Watts: The 'part that can be seen' is the other thing that we don't seem to be doing correctly here. I think we are not taking the clip outer box into account. | 16:11.48 |
| Robin_Watts | hence if we are scaling up by a factor of 1000, then increasing the source area by 1 pixel means adding another 1000 lines. | 16:11.53 |
| | ray_laptop: My previous change to fix 693166 was to take the clip outer box into account. | 16:12.16 |
| | That drastically improved the timings. | 16:12.31 |
| | Essentially we: | 16:13.08 |
| ray_laptop | Robin_Watts: hmm... I need to check that, then. I was seeing interpolated images in all of the bands when the visible portion is only in a subset of the bands | 16:13.10 |
| Robin_Watts | Calculate the device space position of the image. | 16:13.35 |
| | Clip that by the outer rectangle of the clipping path. | 16:13.47 |
| | Map that rectangle back through the inverted transform to see what section of the source image we need. | 16:14.08 |
| | Then we only do interpolation for that 'source region'. | 16:14.49 |
| | Now, if we are near 1:1 in scales, the extra lines added by the fact that the source image region is integer valued is small. | 16:15.26 |
| | IF we're scaling up by 256 say, then every extra line that we include in the source region adds 256 new interpolated lines. | 16:16.06 |
| | ray_laptop: It is possible that I screwed up the calculations as to which bands the image appears in - but I'd hope that there shouldn't actually be any data sent for ones where it's not visible. | 16:17.36 |
| | So my proposed fix for this is to say "if we are interpolating, and we are scaling up by more than 32 on any axis, do the interpolation pre-clist" | 16:18.24 |
| ray_laptop | Robin_Watts: that seems like a reasonable limit, but I am looking with the debugger to see if we are putting data in for bands that don't need it (due to clipping). | 16:20.28 |
| Robin_Watts | great. Another pair of eyes on this to make sure I haven't messed up would be appreciated. | 16:20.54 |
| ray_laptop | If I find anything amiss, I'll post it to the bug. | 16:20.58 |
| henrys | the cluster is not happy. | 16:21.04 |
| Robin_Watts | ressurects the rotated interpolation patch. | 16:21.19 |
| | and misspells it. | 16:21.28 |
| ray_laptop | having to work so hard first thing on Monday is probably making the cluster grumpy | 16:21.46 |
| Robin_Watts | henrys: see marcosw's comment above. | 16:21.53 |
| | ok miha, sorry, what were you saying? | 16:22.26 |
| henrys | Robin_Watts:thanks missed that | 16:22.33 |
| Robin_Watts | I am very impressed how the weather fits in with the spots in America. | 16:22.52 |
| | sports, even. | 16:22.58 |
| henrys | Robin_Watts:now if we can just get earthquakes to cooperate: http://en.wikipedia.org/wiki/1989_World_Series | 16:29.56 |
| Robin_Watts | The "World Series". That's where any team can enter as long as they are from the US, right? :) | 16:32.08 |
| henrys | yes the american definition of world. | 16:36.14 |
| ray_laptop | Robin_Watts: in clist_begin_typed_image we "Calculate a (slightly conservative) Y bounding interval for the image in device space", but we ignore the clipping box. | 16:40.55 |
| Robin_Watts | ray_laptop: Ah. | 16:41.10 |
| | Right. My changes are at lower level than that, I believe. | 16:42.39 |
| henrys | mvrhel, ray_laptop:what's the current limit on separations? | 16:42.44 |
| ray_laptop | Robin_Watts: I'm still stepping through this, so I don't know if that is causing an explosion of work, or not | 16:42.59 |
| Robin_Watts | henrys: with the right compile options, 64. | 16:43.02 |
| | That is CMYK+60 | 16:43.13 |
| ray_laptop | henrys: note, that limit is NOT the number of spot colors we can handle from a file to a CMYK device | 16:44.17 |
| Robin_Watts | ray_laptop: In what way is it not ? | 16:44.44 |
| | oh, with spot color simulation you mean? | 16:45.17 |
| ray_laptop | henrys: if we are going to CMYK, I don't think there is a limit (or a reason to limit things) since we are just using the /Alternate tint transform and the graphics lib just sees the CMYK | 16:45.20 |
| Robin_Watts | right. | 16:45.27 |
| henrys | ray_laptop:I don't think that is gemma's question though is it? | 16:45.38 |
| ray_laptop | henrys: I haven't seen. | 16:45.46 |
| | henrys: haven't looked. Just a moment... | 16:46.13 |
| henrys | ray_laptop:please don't start the big compile-for-customer-argument ... it's monday | 16:47.08 |
| ray_laptop | henrys: We do need to understand if mvrhel's latest change to support OverprintSimulation helps Gemma. Do they really need all of the planes, or just the CMYK with correct OP | 16:48.04 |
| | henrys: I'll give up on the argument (at least w.r.t. Gemma) hoping that we don't do binaries for too many more customers | 16:48.51 |
| mvrhel | they should increase their limit. The OP stuff I did is more for CMYK devices that are not separation devices | 16:49.08 |
| ray_laptop | I don't recall -- what is our default limit ? | 16:49.35 |
| henrys | reading the code it is just GX_DEVICE_COLOR_MAX_COMPONENTS, yes? | 16:50.11 |
| Robin_Watts | Our default limit is 14. | 16:51.16 |
| ray_laptop | In gdevdevn it looks like it is 64 (MAX_SEPARATIONS) | 16:51.45 |
| Robin_Watts | is sure that the actual limit you see when running PDF files is 14. Don't ask me why. | 16:52.14 |
| miha | Robin_Watts: may i msg you? | 16:52.33 |
| Robin_Watts | Sure. | 16:52.41 |
| ray_laptop | oh, MAX_ENCODED_COMPONENTS is 14, but we no longer use encoded colors | 16:53.08 |
| Robin_Watts | See gsccolor.h | 16:53.56 |
| | GS_SOFT_MAX_SPOTS | 16:54.05 |
| | if gemma sends -dMaxSpots=60 the she should be fine. | 16:54.28 |
| | no special build required. | 16:54.38 |
| henrys | so this comment is wrong: /* | 16:55.30 |
| | * Define the maximum number of spot colors supported by this device. | 16:55.30 |
| | * This value is arbitrary. It is set simply to define a limit on | 16:55.30 |
| | * on the separation_name_array and separation_order map. | 16:55.30 |
| | */ | 16:55.36 |
| | #define GX_DEVICE_MAX_SEPARATIONS GX_DEVICE_COLOR_MAX_COMPONENTS | 16:55.36 |
| | | 16:55.39 |
| | in gdevdevn.h | 16:56.18 |
| ray_laptop | henrys: well, that determines the maximum runtime value that MaxSpots can be set to | 16:56.23 |
| | so the code all handles up to 64, but there is a limit of 14 spot colors unless your set MaxSpots (AIUI) | 16:57.16 |
| henrys | I am not saying the code won't do that just verifying the comment is wrong. | 16:58.12 |
| | anyway I'll respond to Gemma's email with what Robin said. | 16:59.08 |
| ray_laptop | henrys: gdevdevn.h comment is correct, but probably should reference gsccolor.h GS_SOFT_MAX_SPOTS and -dMaxSpots | 16:59.53 |
| | it _is_ the absolute maximum (GX_DEVICE_MAX_SEPARATIONS), but there is a 'soft limit' below that | 17:00.47 |
| | henrys: BTW, I hope you don't mind that I sent the patch to Joe on Sat. It just happened to be related to the stuff I'm doing for cust 532 (image interpolation) so I tried what helped Len and it helped a lot on the file. I didn't see a point to making him wait since he was doing email on Sat. | 17:03.25 |
| | tho' it turns out he didn't get around to passing it to his developers until today :-/ | 17:04.01 |
| henrys | nope fine by me. | 17:04.39 |
| Robin_Watts | http://macheist.com/ (for the mac users) | 17:23.49 |
| | mvrhel: ping | 17:32.04 |
| | mvrhel: (For the logs). At the top of image_render_interpolate_icc you have the following line: | 17:48.51 |
| | need_decode = !((penum->device_color || penum->icc_setup.is_lab) && | 17:49.03 |
| | (penum->icc_setup.need_decode == 0) || | 17:49.06 |
| | gs_color_space_is_CIE(pcs)); | 17:49.07 |
| | That's need_decode = !(a && b || c) | 17:49.24 |
| | Can you help my tiny mind with the bracketing please? | 17:49.36 |
| ray_laptop | Robin_Watts: limiting the bands for images to the clip outer box changed the time (with interpolation post-clist) from 159 seconds to 25 and 13 seconds with NumRenderingThreads=4. The patch in gxclimag.c is: | 17:50.04 |
| | - pie->ymin = max(y0, 0); | 17:50.06 |
| | - pie->ymax = min(y1, dev->height); | 17:50.08 |
| | + pie->ymin = max(y0, fixed2int(pcpath->outer_box.p.y)); | 17:50.10 |
| | + pie->ymax = min(y1, fixed2int(pcpath->outer_box.q.y)); | 17:50.11 |
| Robin_Watts | ray_laptop: For how many bands? | 17:50.28 |
| ray_laptop | Robin_Watts: oh, sorry. That's the -dBufferSpace=32m (115 bands) | 17:50.48 |
| Robin_Watts | (I mean, that's excellent news!) | 17:50.53 |
| | For the 1000 band case ? | 17:51.02 |
| ray_laptop | umm... wait a bit, please | 17:51.24 |
| | Robin_Watts: note, that I _still_ like your suggestion to do pre-clist when the image scaling is large and we are interpolating | 17:53.07 |
| | but this might improve some file that do HL images, with or without Interpolation | 17:53.52 |
| | Robin_Watts: WOW! the 1000 band case completes in 185 seconds. | 17:54.42 |
| Robin_Watts | I'd buy that for a dollar. | 17:55.02 |
| ray_laptop | Robin_Watts: I'm going to do a clusterpush with both changes. So a scale factor of 32 sounds like a good cut-off ? (any reason why 32 ?) | 17:57.46 |
| Robin_Watts | ray_laptop: I'd be tempted to just go with yours for now. | 17:58.07 |
| | we should experiment a bit before the 32 one. | 17:58.35 |
| ray_laptop | running an errand. bbiab. | 18:01.51 |
| mvrhel | Robin_Watts I am here now sorry | 18:08.32 |
| Robin_Watts | mvrhel: no worries. | 18:08.39 |
| | I'm afraid my tiny brain is unable to parse that line. | 18:08.49 |
| mvrhel | hehe that is a bad one | 18:10.05 |
| | so what is it that you want to do | 18:10.17 |
| Robin_Watts | mvrhel: I want to remove the warning on that line :) | 18:10.54 |
| | (I've duplicated that line into my image_render_interpolate_landscape_icc function, and adding a warning offends me :) ) | 18:11.27 |
| mvrhel | ok so we need to decode in the following cases | 18:11.32 |
| | hold on let me look at the code | 18:12.04 |
| | we will certainly need to decode if penum->icc_setup.need_decode is true | 18:13.12 |
| | let me try to recall why penum->device_color is in this | 18:14.32 |
| Ch3rryC0ke | Hey there-- has anyone been able to compile mupdf for ARM in Visual studio? | 18:14.52 |
| Robin_Watts | Ch3rryC0ke: No one here has tried. | 18:15.04 |
| | I cannot see why it should not work though. | 18:15.17 |
| Ch3rryC0ke | Robin_Watts: Thanks.. I'm trying to get it to work, but I can't figure out what arguments I need to pass to get it working properly-- for example a lot of the 3rd party libs fail because they are calling x86 assembly instructions. | 18:15.56 |
| | I'm trying to look at the iOS make files to understand what they pass they trigger the proper actions | 18:16.42 |
| Robin_Watts | PRobably because they mistakenly assume that MSC_VER means x86. | 18:16.44 |
| Ch3rryC0ke | Ah, so I can undefine that-- is there something that I can define that will mean ARM? | 18:17.54 |
| | I was trying to define _M_X64 to avoid the assembly but that doesn't fully work | 18:18.12 |
| Robin_Watts | Any call to microsoft C will have MSC_VER defined. | 18:18.37 |
| Ch3rryC0ke | I'm also getting a lot of errors (over 100) along the lines of: | 18:19.14 |
| | "Error49error C2719: '_A': formal parameter with __declspec(align('16')) won't be aligned (..\thirdparty\openjpeg-1.5.0-patched\libopenjpeg\j2k_lib.c)" | 18:19.15 |
| Robin_Watts | I have no idea about that. I'd need to look at the source. | 18:20.17 |
| chrisl | You can "undefine" a defined preprocessor directive with /U<name> | 18:20.34 |
| Ch3rryC0ke | chrisl: thanks, I'll try that | 18:20.53 |
| | Robin_watts: It seems to error in FP arithmetic, some of the lines look like this: | 18:21.06 |
| | extern __m128 _mm_add_ss(__m128 _A, __m128 _B); | 18:21.08 |
| chrisl | Ch3rryC0ke: Use it with care, though...... | 18:21.15 |
| Robin_Watts | Right, that's a predefinition of a compiler intrinsic. | 18:21.31 |
| | It should only be doing that once it thinks it knows what toolchain/arch it is running for. | 18:21.53 |
| Ch3rryC0ke | Hmm.. so where should I start? Are the flags specified in Makerules/makefile/makethird compiler specific? Should I try adding those flags to Visual Studio? | 18:27.24 |
| Robin_Watts | Ch3rryC0ke: Well, if it was me, I'd look at the errors and work out what definitions were causing it to get to the error positions. | 18:29.07 |
| Ch3rryC0ke | OK, I'll work my way through those | 18:31.16 |
| | What exactly does the "generated" VS project do? I've included it as a dependency because VS was complaining without it, but I'm not sure exactly why it's needed. | 18:31.49 |
| mvrhel | Robin_Watts: gs_color_space_is_CIE(pcs) is always going to be returning true except for the cases of a separation, DeviceN or indexed color space which will need the decode step so I have to think that the last || should be a && | 18:34.00 |
| Robin_Watts | !((a || b) && c && d) | 18:37.19 |
| mvrhel | yes | 18:37.46 |
| | you are going to want to cluster push this though | 18:38.02 |
| Robin_Watts | I'd still like to understand it though. | 18:38.21 |
| mvrhel | well we are trying to decide what cases need an extra decode step | 18:38.40 |
| Robin_Watts | gs_color_space_is_CIE(pcs) => need_decode = 1 | 18:38.41 |
| mvrhel | index, deviceN, separation colors spaces | 18:38.59 |
| | require some extra transformations | 18:39.05 |
| | certain source values have extra mappings that need to occur before the ICC mapping can occur | 18:39.37 |
| | so we need an extra buffer allocation | 18:39.45 |
| Robin_Watts | ok. | 18:39.59 |
| mvrhel | these occur also with lab color spaces | 18:40.05 |
| | and some postscript cases where the values are inverted or have some weird mapping applied to them | 18:40.26 |
| Robin_Watts | So gs_color_space_is_CIE(pcs) ==0 => need_decode = 1 | 18:40.39 |
| mvrhel | that is one case yes | 18:40.51 |
| | for example, if I have an indexed color space | 18:41.02 |
| | then need_decode will get set to 1 | 18:41.14 |
| | if I have an icc space then gs_color_space_is_CIE(pcs) == 1 | 18:41.38 |
| | and this part will not work into the decode decision | 18:41.49 |
| | but I could have an lab space | 18:42.00 |
| | and gs_color_space_is_CIE(pcs) == 1 | 18:42.07 |
| Robin_Watts | Aha. I think I have a way that fits it into my head. | 18:42.08 |
| | The only time we ever don't want to decode, is when the icc_setup says not to decode, AND the colorspace isn't indexed/separation/deviceN AND it's a non LAB device space. | 18:42.58 |
| mvrhel | right. | 18:44.33 |
| | there are a couple different types of LAB spaces running around though | 18:44.50 |
| | iirc | 18:44.53 |
| | some that require a decode step and some that dont | 18:45.05 |
| | which is likely the reason for the || | 18:45.30 |
| | in the first part | 18:45.34 |
| Robin_Watts | I'm struggling to find a way to make this comprehensible to mere mortals such as myself. | 18:46.06 |
| mvrhel | well I think you have it now | 18:46.31 |
| Robin_Watts | image_render_interpolate has need_decode = !(penum->device_color || gs_color_space_is_CIE(pcs) || islab); | 18:47.33 |
| mvrhel | thats a different animal | 18:47.54 |
| | that does the ICC stuff differently | 18:48.13 |
| Robin_Watts | Shame, cos I can understand that one :) | 18:48.24 |
| mvrhel | well when you do all the && in the others it is simple | 18:48.43 |
| | just think of dont_decode when we have a nice clean ICC color space that our image data is already in. Then we just do the CMM transform. no messy index color spaces or funny postscript mappings | 18:50.32 |
| | hmm. Now I am a little worried about the gs_color_space_is_CIE(pcs) | 18:51.58 |
| | case | 18:51.59 |
| | no that should be ok since we will be using the equivalent ICC profile | 18:52.20 |
| | which should include the decoding stuff | 18:52.34 |
| Robin_Watts | If we apply demorgans law to !((a || b) && c && d) we get (!a && !b) || !c || !d | 18:52.47 |
| mvrhel | I was thinking about the CIEDEF(G) color spaces | 18:52.51 |
| Robin_Watts | which is: decode if (the icc stuff says we need to decode) OR (it's indexed) OR (it's separation) OR (it's devN) OR (it's a nonlab-non device color) | 18:53.51 |
| mvrhel | You can redo it how ever you want. Just know that we have decoding operation to perform in the cases that I said | 18:53.53 |
| | yes | 18:54.18 |
| Robin_Watts | because lab colors are the only non-device colors that we can do without decoding ? | 18:54.42 |
| mvrhel | likewise we do not need to decode if it is a nice clean ICC color space | 18:54.51 |
| | again. lab is fraught with issues in many places due to the manner in which is it defined in multiple ways | 18:55.19 |
| | it could be an ICC color space with an lab ICC profile | 18:55.32 |
| Robin_Watts | What I gave above is an exact statement of what your modified condition will do. | 18:55.53 |
| mvrhel | it could be encoded in a postscript manner L [100, 0] a [-128, 127] b [-128, 127] | 18:56.00 |
| | or it could be 0 to 255 | 18:56.11 |
| | Robin_Watts: I am fine with what you gave | 18:56.22 |
| Robin_Watts | If there are cases where it doesn't work, then either the condition is wrong (and needs to be fixed), or I cocked up translating it into english. | 18:56.26 |
| | OK. | 18:56.28 |
| mvrhel | To me they read the same | 18:56.39 |
| Robin_Watts | Fair enough, thanks. | 18:56.49 |
| | I'll try a cluster push with that change. | 18:56.54 |
| mvrhel | That said, there are some weird cases lurking out there and it would be good if we could run with -dDOINTERPOLATE to compare | 18:57.27 |
| | going to grab some lunch bbiab | 18:58.29 |
| ray_laptop | Robin_Watts: so, I threw together a test for pre vs. post clist interpolation which is based on the number of support lines (scaled to destination space) time the number of bands in the image compared to the band height. When the ratio is too large, I punt. | 19:39.56 |
| | Robin_Watts: this lets us do 11 of the images with smaller scaling post-clist (which makes NumRenderingThreads=4 about 15% faster) | 19:42.02 |
| Robin_Watts | ok. | 19:42.41 |
| ray_laptop | Robin_Watts: but I also want to look at skipping interpolation pre-clist when we are too far outside the clip box (similar to what happens when using the clist mode) | 19:44.48 |
| Robin_Watts | ray_laptop: Don't we do that already? | 19:45.14 |
| | My original changes for the bug weren't clist specific were they? | 19:45.42 |
| | Which means they should kick in whenever we process pre-clist. | 19:46.26 |
| ray_laptop | Robin_Watts: Oh, I just now saw them. However you expand the irect when you are NOT interpolating (gxipixel:387) | 19:56.43 |
| | Robin_Watts: with your enhancement in the pre-clist interpolation to skip inactive source rows, pre-clist interpolation should be faster anytime the cost of interpolating 'support' lines exceeds the cost of writing and reading back the copy_color commands, which is probably anytime we cross a band boundary. Now the clist will be larger because we are writing the expanded (interpolated) data. | 20:18.25 |
| | Robin_Watts: so I'm not sure how often (or if) we ever want to do post-clist interpolation. | 20:19.42 |
| | have to go cut grass. bbiaw | 20:20.21 |
| henrys | hi marcosw how goes it? | 22:46.06 |
| marcosw | okay | 22:46.12 |
| henrys | I noticed macpro was disabled did I break something? | 22:47.44 |
| marcosw | henrys: I didn't disable it. It's been downed for a while, before you left for Chicago. I assumed you had done it. Maybe Robin_Watts noticed something wrong with it? | 22:51.55 |
| henrys | hmm I just tried to enable it it says putting macpro back on the cluster but nothing happens. Robin_Watts didn't know about it either | 22:54.38 |
| | does it take time to reenable itself. | 22:55.05 |
| Robin_Watts | henrys: The web thing for enabling/disabling doesn't work currently. | 22:58.23 |
| henrys | so I should just rm the macpro.down file? | 23:04.40 |
| | bbiab | 23:12.06 |
| Robin_Watts | henrys: Yes, if we think it's safe to bring back up. | 23:45.47 |
| | Forward 1 day (to 2012/10/23)>>> | |
IRC Logs