| | <<<Back 1 day (to 2013/01/14) | 2013/01/15 |
| Robin_Watts | liucougar: I did. zeniko is right. I have a review on my git repo waiting for tor8 to review it to fix it. | 00:20.05 |
| liucougar | Robin_Watts: cool, thanks | 00:54.55 |
| mvrhel_laptop | good night all | 06:17.25 |
| sebras | alexcher: if you need some additional info on bug 693513 I'm happy to help. :) | 10:06.55 |
| Robin_Watts | Morning tor8 | 10:44.08 |
| | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=16151f7cdc3767c50c2793d362e9232bc6c1da72 | 10:44.25 |
| sebras | Robin_Watts: lgtm. | 10:45.30 |
| Robin_Watts | sebras: thanks. | 10:46.09 |
| tor8 | Robin_Watts: right. commit away. | 10:46.16 |
| Robin_Watts | tor8: Done. thanks. | 10:48.21 |
| paulgardiner | deleet: ping | 10:56.02 |
| deleet | paulgardiner: pong | 10:56.48 |
| paulgardiner | deleet: Hi. Your improvements to bitmap recycling: do you know if both parts were needed to fix your problems? Were wondering if it might be possible to do without the call to recycle because we're not sure how it will interact with another thread still rendering to the bitmap. | 10:59.07 |
| | deleet: if the call h.setBm(null) alone fixes your problem, we might leave out the call to recycle. | 10:59.54 |
| deleet | It will not fix the issue and, I've come to verify, not even on Android 4.x | 11:00.26 |
| | You need the recycle call because the bitmap data is cleared by a finalizer in java .. so it may takes a few iteraterations of the GC to actually clear it from memory | 11:01.03 |
| | calling recycle() explicitly frees it up on the next GC run (and not a few ones later) | 11:01.21 |
| | on Android 2.x however, recycle() is required as bitmap data is not stored in the VM heap but in native heap .. meaning it probably won't be cleared anytime soon | 11:02.05 |
| | so the conclusion is: android 4.x and 2.x both should have the recycle call. You could synchronize the method to ensure no other thread is writing to the bitmap (which I believe it is) to avoid the problem you described | 11:03.30 |
| paulgardiner | deleet: so even after a call to recycle, if a reference still exists the bitmap wont get GC'd? | 11:03.31 |
| deleet | paulgardiner: if there is a reference elsewhere, it will be invalid I believe .. but won't be GC'd untill all references are cleared | 11:04.14 |
| | you can call: http://developer.android.com/reference/android/graphics/Bitmap.html#isRecycled() to check | 11:04.30 |
| Robin_Watts | The current code has the reference protected by a "synchronize", but there may still be another reference elsewhere. | 11:04.57 |
| | The worry is that if we call recycle, the other thread that may still be accessing through the other reference may end up accessing data that does not exist, and crash. | 11:05.32 |
| deleet | that's where you should check for isRecycled then .. but I haven't experienced that crash | 11:06.37 |
| paulgardiner | The other thread is likely accessing the bitmap memory, rather than the object | 11:06.39 |
| deleet | ah, I see | 11:06.48 |
| paulgardiner | deleet: did your problem occur only on 2.x? | 11:07.15 |
| deleet | no, 4.x as well. | 11:07.21 |
| | the bitmap memory may be cleared after you call recycle(), I would have to look in the Android source to find out exactly | 11:07.52 |
| paulgardiner | do you have a link to the bug? | 11:07.53 |
| deleet | http://bugs.ghostscript.com/show_bug.cgi?id=693546 this one? | 11:08.30 |
| Robin_Watts | Supposedly in later androids the bitmap memory is stored in the heap with normal objects. | 11:09.07 |
| deleet | yes, as of Android 3.0 | 11:09.15 |
| paulgardiner | I wonder why we haven't seen this before. We've madly zoomed on many devices. | 11:09.39 |
| Robin_Watts | Hopefully therefore the other thread holding a reference to the bitmap memory in which it is working should mean that the recycle doesn't trash it. | 11:09.41 |
| deleet | paulgardiner: two zooms on a transformer pad crashed it immediately :( | 11:09.57 |
| Robin_Watts | paulgardiner: deleet is using a transformer prime, so a 1920x1200 screen. | 11:10.02 |
| | so a large amount of memory - but that was one of our test devices too. | 11:10.19 |
| deleet | it allocated > 40mb memory just for mupdf alone at a point | 11:10.21 |
| paulgardiner | Robin_Watts: is your prime 720? | 11:10.37 |
| Robin_Watts | I have a TF201, iirc. | 11:11.11 |
| | 1200x800. deleet - what model number is yours? | 11:11.42 |
| deleet | from the recycle() docs: This will not free the pixel data synchronously; it simply allows it to be garbage collected if there are no other references. | 11:12.31 |
| Robin_Watts | deleet: Ah, that sounds good. | 11:12.44 |
| deleet | Robin_Watts: I think mine is a TF770 ? I am not 100% sure | 11:12.52 |
| Robin_Watts | There is a "transformer infinity" ? | 11:13.24 |
| deleet | TF700 yeah | 11:13.26 |
| | http://www.gsmarena.com/asus_transformer_prime_tf700t-4421.php | 11:13.51 |
| paulgardiner | I guess the most likely problem would be that the memory gets reused for another bitmap and we have two renders to the same bitmap, but the fact that our render calls are sequentialised should stop that causing probelms. | 11:13.52 |
| deleet | paulgardiner: your bitmap handling is from native? or Java | 11:14.25 |
| paulgardiner | native | 11:14.34 |
| Robin_Watts | deleet: well,a bit of both really :) | 11:14.44 |
| paulgardiner | yeah actually | 11:14.52 |
| | all rendering from native | 11:15.02 |
| Robin_Watts | All the rendering INTO the bitmap happens from native code. | 11:15.26 |
| | The rendering OF the bitmap onto the screen happens in java. | 11:15.39 |
| deleet | Right. I think that if your methods are sequential/synchronized, you should be ok as no single bitmap will be drawn by two threads | 11:16.39 |
| paulgardiner | At the point where recycle is called, a thread may still be doing native access to the bitmap data but it is certain that we don't need the result of that render. | 11:17.03 |
| deleet | Yes and the pixel data isn't recycled yet as there's a reference to it stil .. only when you release that references it will be gone | 11:17.34 |
| Robin_Watts | The native code that draws into the bitmap is NOT protected by the sequential thing. BUT I don't think that matters, given the most recent thing you posted from the docs (that recycle won't do away with the data if it's still in use) | 11:18.03 |
| | So I think the code we have now is safe. | 11:18.13 |
| paulgardiner | We will have called AndroidBItmap_lockPixels and I'd hope that was thread safe. | 11:19.49 |
| Robin_Watts | goes for a run. back later. or quite soon if it's too cold. | 11:19.49 |
| deleet | sounds good | 11:20.48 |
| paulgardiner | Ah right. I think it should be okay. Thanks deleet. We can see if Robin_Watts has any further worries when he gets back, but currently it looks good to me. I forgot about the locking and unlocking of the pixel data in the native code. | 11:21.20 |
| deleet | no probem | 11:21.43 |
| deleet | fails at typing today | 11:21.52 |
| Robin_Watts | no extra worries. | 13:03.22 |
| | We need moar cluster power, captain! | 15:09.57 |
| alexcher | Robin_Watts: We need to figure out how to use less poserful computers. For instance, specialize nodes to avoid compiling everything. | 15:14.16 |
| Robin_Watts | The build times are insignificant, I believe. | 15:33.38 |
| | I suspect we'd achieve a lot more by culling the test files. Perhaps by using a transitive closure of implication on the historical data. | 15:34.19 |
| | We generate a table of 0's and 1's for every revision, and every file. | 15:34.50 |
| | If a file changes it's md5 at a given revision, it gets a 1, otherwise it gets a 0. | 15:35.13 |
| | Then we look for files whereby "whenever file X changes, file Y changes too", we know it's not worth checking file Y. | 15:36.48 |
| henrys | I don't get it file X tests file Y tests A B and C whenever X fails y fails so we remove it and don't test B and C. | 15:40.51 |
| | sorry file X tests A | 15:41.12 |
| Robin_Watts | Sorry, I got it the wrong way around. | 15:44.18 |
| | If "Whenever X changes, Y changes too", we don't need to test X. | 15:44.32 |
| | as we know Y will test all the same features. | 15:44.41 |
| henrys | worth talking about at the meeting. A simpler thing is to just shovel more stuff to the overnight but your idea would improve our testing bang for the buck ... | 15:49.42 |
| Robin_Watts | I should do the test to see how much it would reduce our test size. | 15:50.12 |
| henrys | it would be good to have a time breakdown of each directory | 15:52.36 |
| | i.e. comparefiles ... | 15:52.56 |
| Robin_Watts | Rays favorite company have asked me to be on a con-call with them at 17:30 today | 15:53.00 |
| | (9:30 PST) | 15:53.06 |
| kens | oh what fun | 15:53.37 |
| Robin_Watts | They have questions about our scan conversion stuff, specifically the fact that we seem to be spending a lot of time in spot_into_trapezoids. | 15:53.54 |
| | 10 minutes to form/mupdf meeting? | 15:54.13 |
| kens | I'#ve sen their email | 15:54.24 |
| henrys | Robin_Watts: 3 meetings in a row. | 15:54.57 |
| Robin_Watts | mmm. and I was thinking of trying to give up diet coke this week... | 15:58.49 |
| henrys | so we begin looks like it should go fast | 16:02.50 |
| | anything on google play? | 16:03.07 |
| Robin_Watts | I got a message back from the DMCA guys saying "We need more information" today. | 16:03.24 |
| henrys | should I reping miles and scott. | 16:03.32 |
| | ? | 16:03.33 |
| Robin_Watts | and I answered their mail. | 16:03.40 |
| | henrys: Miles' plan was to "Wait a week to see if the company got in touch" | 16:04.02 |
| henrys | oh okay | 16:04.13 |
| | I didn't see his response, did I miss it? | 16:04.51 |
| Robin_Watts | He took tech off the distribution list for some reason. | 16:05.06 |
| | But... I do have a properly signed build now, so in theory we can put it on google play (we'd just have to change the package name to com.artifex.mupdf11 or something). | 16:08.38 |
| henrys | Robin_Watts: can we change it back once miles resolves the issues or is that package name in some google infernal database. | 16:10.09 |
| Robin_Watts | It's in some google infernal database, I think. | 16:10.23 |
| | The way I knew there was a problem was that when I tried to upload the build it told me that someone had beaten me to it. | 16:10.42 |
| henrys | right but you would think if this person gets a spanking from google they'd remove the name. | 16:11.12 |
| Robin_Watts | Changing the name back may not be a big deal, but I suspect it will cause a duplicate entry on the store, and people won't be able to auto update or something | 16:11.29 |
| | yeah, you'd hope. | 16:11.32 |
| henrys | tor8:anything for the meeting? | 16:12.09 |
| Robin_Watts | It's possible google may apply their "once it's been used once, you can never use it again" rule though, like they do with email addresses. | 16:12.13 |
| henrys | paulgardiner: looks like your moving along with annotations, nice! | 16:14.03 |
| deleet | they have like 200 downloads | 16:14.04 |
| | screw them, get your name back | 16:14.12 |
| paulgardiner | henrys: Seems to be going okay. In a maze of twisty JNI passages at the moment. | 16:15.21 |
| henrys | Robin_Watts: just trying to decide if we should wait and see if Miles can get rid of this guy or we should just go with a new name. I feel everyday we aren't on google play is bad. | 16:15.43 |
| Robin_Watts | henrys: Well, changing the name is a pain in the ass, cos it's a matter of renaming files in the git repo etc. | 16:16.16 |
| | (it's not hard to do, it's just nasty) | 16:16.35 |
| henrys | okay so let's wait | 16:16.45 |
| paulgardiner | I'd think it was quite likely that Google wont let us use the original because installing our app would then break the "illegal" one, for users who had bought it in good faithe | 16:16.47 |
| Robin_Watts | I am hoping that google will give us a swift resolution. | 16:17.01 |
| sebras | paulgardiner: it's free...? | 16:17.37 |
| paulgardiner | Could we rename just for the release (with a script maube) and not change the repo? | 16:17.46 |
| Robin_Watts | It's free, so no "bought" issues ,but... | 16:17.49 |
| | paulgardiner: We could, but I'd rather avoid it. | 16:18.04 |
| henrys | yeah what does happen with updates? | 16:18.12 |
| | assuming we get our name back? | 16:18.28 |
| Robin_Watts | Given that both artifex and mupdf are our trademarks, com.artifex.mupdf should fairly obviously be ours to use :) | 16:18.30 |
| | henrys: It's possible that people will automatically update from SmartIBook to MuPDF. | 16:18.49 |
| | So those 200 downloads would be ours. All ours. Muhahaha. | 16:19.00 |
| sebras | Robin_Watts: :) | 16:19.05 |
| paulgardiner | -) | 16:19.11 |
| | :-) even | 16:19.14 |
| tor8 | Robin_Watts: have you tried just renaming in the xml manifest and not touching the java class names? | 16:19.57 |
| Robin_Watts | tor8: I have not, I will do so in a bit. | 16:20.21 |
| tor8 | Robin_Watts: if so, that's probably the way to go with com.example.mupdf as we discussed last week | 16:20.43 |
| Robin_Watts | or com.artifex.mupdf.demo or something, yes. | 16:20.57 |
| henrys | okay so anything else for the meeting? can we call it early? | 16:22.11 |
| paulgardiner | I'm good | 16:22.25 |
| Robin_Watts | I've not done any more on the openjpeg stuff really - got sucked back into gs stuff. So I have nothing else. | 16:22.43 |
| sebras | tor8: Robin_Watts: someone appears to have registered com.example at least... https://play.google.com/store/apps/details?id=com.example | 16:22.51 |
| Robin_Watts | hmm. Is the android build broken at the moment? | 16:23.23 |
| tor8 | sebras: well, hopefully nobody would try to upload a com.example build (just use it for internal testing) | 16:23.40 |
| Robin_Watts | R.animator.info <- no animator ? | 16:23.48 |
| sebras | tor8: right, and if they do then they would get a clash. | 16:24.06 |
| paulgardiner | Eek! Did I not commit that?! | 16:24.16 |
| sebras | tor8: actually it might be a good idea to use just com.example if you can since there is already an app named that way on google play. | 16:25.09 |
| | besides it would align with rfc2606... ;) | 16:25.21 |
| Robin_Watts | sebras: The fact that com.example is used on google play means we can't use it, AIUI. | 16:25.36 |
| sebras | Robin_Watts: why? | 16:25.46 |
| | Robin_Watts: for local compiles that ought to work fine..? | 16:25.57 |
| Robin_Watts | oh, I see, you mean so that all future people couldn't... yeah I follow. | 16:26.02 |
| sebras | exactly. | 16:26.08 |
| Robin_Watts | Once we get our app up the no one else will be able to use the code unchanged. | 16:26.33 |
| paulgardiner | Robin_Watts: res/animator/info.xml was commited. I'm not sure how in non-eclipse builds you regenerate R. | 16:27.18 |
| tor8 | Robin_Watts: but if the error says "com.example" they may get a hint instead of just scratching their heads | 16:27.26 |
| | paulgardiner: ant regenerates R, but the dependency is broken so you often have to "ant clean" | 16:28.05 |
| sebras | Robin_Watts: maybe you could add a footnote on the mupdf page that if someone is looking for smartIBOOK to go to their webpage. | 16:28.10 |
| Robin_Watts | sebras: Let's see if they take a license first, eh? :) | 16:28.30 |
| | ant clean && ant release didn't work. | 16:28.41 |
| sebras | Robin_Watts: does that matter? don't you want to claim com.artifex.mupdf anyway? | 16:28.50 |
| | on google play that is. | 16:29.06 |
| paulgardiner | tor8: ah right. That'll be it then hopefully. In eclipse I often have to add a char to a file remove it again and then resave to trigger these sorts of things. | 16:29.06 |
| Robin_Watts | sebras: Yes. But I don't care if people can't find them afterwards :) | 16:29.12 |
| sebras | Robin_Watts: ah. :) | 16:29.23 |
| henrys | there is something screwy with windows stdin -from my limited sampling so far short jobs good, long streams EOF in the middle of the job. Reading from a file works fine. | 16:37.14 |
| | we really do need better MS QA | 16:37.52 |
| tor8 | henrys: windows stdin is wonky. make sure you don't have any ^Z in the input, or it'll end-of-data the stream | 16:38.28 |
| kens | and iuf you use image data, it will have a ctrl-z | 16:38.54 |
| | not to mention LZW/flate compressed data | 16:39.25 |
| | Basically, don't use stdin on Windows | 16:39.38 |
| henrys | oh I do have image data - so this just doesn't work and we don't expect it to | 16:39.49 |
| kens | Its 'not our fault' | 16:40.13 |
| henrys | so stdin is no a binary stream. | 16:40.30 |
| | on windows | 16:40.40 |
| kens | It is binary, but.... | 16:40.43 |
| | It treats some control characters specially | 16:40.55 |
| | Like I said, don't do that. | 16:41.03 |
| henrys | well our documentation is not terribly clear about that should that be changed? | 16:41.51 |
| kens | Hmm, well stdin is at fault, and we don't control that.... | 16:42.17 |
| | I suppose it might be helpful to mention it (Don't try this on Windows kidss!) | 16:42.43 |
| kens | coffees | 16:43.59 |
| Robin_Watts | tor8: OK, the 'R' problem turns out to be because I'd renamed the package name in AndroidManifest.xml | 16:46.24 |
| | so we do need to rename files etc to change the name :( | 16:46.41 |
| | ray_webchat: Have you been looking at bug 693541? | 16:47.38 |
| | You mentioned on here that you were looking at that the other day, but then went on to describe a different crash than the one I was seeing. | 16:48.02 |
| | The problem I see is unrelated to clist. | 16:48.13 |
| ray_webchat | I am waiting at the doctor's office. Sorry I forgot to send email. | 16:48.48 |
| | they have wi-fi here, but it doesn't pass IRC, so I have to do webchat. | 16:49.10 |
| | I'll chat later... | 16:49.25 |
| Robin_Watts | ray_webchat: OK. I am due to be on a con-call with your customer at 9:30am PST. | 16:50.20 |
| henrys | kens:mr google says _setmode(_fileno(stdin), O_BINARY) | 16:58.49 |
| kens | Hmm, well it might work | 16:59.03 |
| | TBH does nayone really use stdin on Windows ? | 16:59.12 |
| | But Iguess its worth fixing if its as easy as that | 16:59.42 |
| henrys | kens:see 693543 | 17:00.41 |
| mvrhel_laptop | good morning | 17:00.52 |
| henrys | mvrhel_laptop: fixing bugs faster than marcosw can respond. | 17:01.26 |
| kens | henrys probably still shouldn't crash though | 17:01.33 |
| henrys | kens:yes indeed | 17:01.44 |
| | alexcher:you now have jbig2dec please feel free to bounty things out to shelly | 17:03.10 |
| kens | Its worth fixing stdin if its easy, at least I could mimic Marcos' cluster command line then | 17:03.11 |
| mvrhel_laptop | henrys: did miles tell us yet to buy tickets? | 17:03.14 |
| kens | mvrhel_laptop: no | 17:03.22 |
| mvrhel_laptop | ok | 17:03.27 |
| Robin_Watts | mvrhel_laptop: not that I've seen. | 17:03.28 |
| henrys | mvrhel_laptop: he did not. | 17:03.32 |
| | I wish we could skip one ;-) | 17:03.59 |
| alexcher | henrys: I need to figure out first, which bugs can be quickly closed, and which ones need outside help. | 17:04.28 |
| henrys | but then Robin_Watts wouldn't get his milk shake and he'd be cranky | 17:04.34 |
| mvrhel_laptop | Max has not replied to my ETS question. I am going to go ahead and make him some examples from the files that he gave me and see what he says about that | 17:04.40 |
| | I am making a bit of progress on the metro viewer. spending most of my time fighting with c++ crap and the file streams hopefully once I get through that things will come together quickly | 17:05.39 |
| henrys | Robin_Watts: if you need to prepare for your next meeting please go ahead. | 17:05.44 |
| mvrhel_laptop | I think I have one blocker also before the release | 17:06.00 |
| chrisl | alexcher: you probably want to punt the jbig2dec build bugs back to me | 17:06.04 |
| mvrhel_laptop | and no word yet from customer 330 with respect to them integrating my color fixes that I did for them | 17:06.29 |
| henrys | chrisl: yes I noticed that was misassigned. | 17:06.48 |
| chrisl | henrys: well, marcosw just did as he was told.... | 17:07.20 |
| henrys | marcosw:there have been noises about the speed of the clusters do you have a time breakdown of each individual directory? | 17:07.22 |
| Robin_Watts | henrys: I've made tea, so I am prepared :) | 17:07.34 |
| henrys | chrisl: yup my bad | 17:07.37 |
| alexcher | chrisl: you are always welcome to fix anything that looks simple to you. | 17:07.40 |
| chrisl | alexcher: most of the build ones aren't that simple :-( | 17:07.58 |
| henrys | alexcher:do assign it back to chrisl or I will let me know if you want me to do it. | 17:08.11 |
| alexcher | henrys: OK, I'll do it. | 17:08.46 |
| henrys | marcosw:we did discuss making pcl 300 instead of 600 also which will move things along. | 17:09.11 |
| marcosw | sorry, I'm only paying partial attention. | 17:10.28 |
| | I'm in a meeting at Uni. | 17:11.08 |
| henrys | tor8:I hate to mention this but have you looked at Qt for the viewer? Maybe C++ is the lesser evil here. | 17:11.38 |
| marcosw | I can generate a time for each cluster test directory and each test in time for next week's meeting. | 17:11.45 |
| henrys | marcosw:read the logs when you have a chance. | 17:11.48 |
| tor8 | henrys: I'll take a look if win32 turns out horrible. I haven't poked at the win32 port yet. been busy with mupdf cleanups, docs and procrastination... | 17:13.34 |
| henrys | anything else meeting wise, I can't think of anything. | 17:13.39 |
| tor8 | henrys: Qt has horrible startup times though | 17:13.58 |
| | all Qt apps I've seen have taken seconds to launch | 17:14.13 |
| kens | henrys did you get my mail re customer #1 ? | 17:15.16 |
| henrys | kens:I don't think so. | 17:16.05 |
| kens | Oh, let me check if it got stuck | 17:16.17 |
| chrisl | henrys: I have some stuff for URW - there's a glyph in a few of the fonts which looks incorrectly positioned, or the width is wrong, and a list of width metrics that look dubious, compared to the Adobe fonts I have available, and could do with reviewing. Can I send it to you to pass on? | 17:16.31 |
| kens | It did I'll send it now | 17:16.33 |
| henrys | chrisl:please do. | 17:16.48 |
| chrisl | Cool, I'll do that tomorrow | 17:16.57 |
| | thanks! | 17:17.00 |
| kens | Weird Eudora doesn't want to send my mail.... | 17:17.45 |
| henrys | geez been a while since we've had a day above freezing temp. | 17:18.34 |
| mvrhel_laptop | I think we steer clear of Qt | 17:19.03 |
| | I am going to get through this windoze stuff | 17:19.09 |
| marcosw | it's probably been discussed and I've missed it, but do we have a tentative release date for 9.07? | 17:19.36 |
| kens | OK henrys mail sent now | 17:20.15 |
| henrys | I think the goal is always the 1st of the month then we come up with reasons why that is too soon. | 17:20.32 |
| chrisl | henrys: I was thinking of an rc in the first week, then aim for the release second week in Feb? | 17:21.24 |
| henrys | chrisl:sounds right. | 17:21.52 |
| chrisl | So now we wait for all the reasons to delay.... :-) | 17:22.14 |
| henrys | kens:okay reading now. | 17:23.21 |
| mvrhel_laptop | wow. that is coming up fast | 17:23.41 |
| | I better get to cracking on my blocker | 17:23.50 |
| chrisl | mvrhel_laptop: I'm not aware of any pressing deadlines, so if you need longer, just yell | 17:24.31 |
| mvrhel_laptop | ok | 17:24.39 |
| marcosw | mvrhel_laptop: I'll try to enter all the bugs which are blockers that I've been saving up in another week or two :-) | 17:25.54 |
| mvrhel_laptop | perfect | 17:26.13 |
| henrys | kens:relevance to other users? | 17:26.28 |
| | kens:also fine to pass this on to support others may want to weigh in. | 17:27.25 |
| kens | henrys I'm not aware of anyone else asking for this, I'll CC the mail to support | 17:27.45 |
| chrisl | henrys: in case you think there was a typo, I just sent you a mail about my current project - I will get the URW stuff to you tomorrow, as I said | 17:32.50 |
| henrys | chrisl:do some type 1's work - is this a good place for a fallback? | 17:35.10 |
| | kens:how close are you to finishing color management - still a ways to go? | 17:36.48 |
| | kens:this is much easier if not top 10 | 17:37.48 |
| | sorry I don't mean to keep anyone past the 1/2 hour. | 17:39.47 |
| chrisl | henrys: yes, most do. I could have it do "pure" type 1 and then use freetype for others, but if we have freetype, we might as well use it for all, I reckon | 17:40.57 |
| henrys | chrisl: I would prefer try the third party scaler and if it fails use free type. | 17:42.22 |
| | as a fallback | 17:42.36 |
| | much easier to explain that to customers | 17:42.43 |
| chrisl | henrys: well, we can't do that, but I can identify the class of fonts where the problem lies, and punt those to freetype | 17:43.30 |
| henrys | chrisl:okay good enough | 17:43.46 |
| chrisl | OKay, I'll do that, thanks. I have to go - 'nite all! | 17:44.44 |
| henrys | bye chrisl | 17:44.54 |
| Robin_Watts | liucougar: Fix pushed. | 18:01.36 |
| henrys | Robin_Watts: good meeting? | 18:12.55 |
| mvrhel_laptop | ok. I actually have the dumb windows stream wrapped up in the fitz stream and fz_open_document_with_stream is reading in the data fine with my windoze managed reader proc | 18:22.13 |
| | now let me see if I can render a page | 18:22.30 |
| | oh I also meant to ask kens how the pdfwrite color stuff was going and if he needed anything from me | 18:24.09 |
| | hmm Robin_Watts or to8 silly question for you | 18:36.08 |
| henrys | mvrhel_laptop: kens seems to have left but didn't sign out. | 18:36.16 |
| mvrhel_laptop | henrys: yes. I was guessing that was the case | 18:36.34 |
| henrys | as he usually does | 18:36.36 |
| mvrhel_laptop | Robin_Watts or tor8, where is fz_page_s defined? | 18:36.58 |
| Robin_Watts | mvrhel_laptop: Looking now. | 18:39.01 |
| mvrhel_laptop | oh good thanks | 18:39.07 |
| Robin_Watts | typedef struct fz_page_s fz_page; | 18:39.35 |
| | in fitz.h | 18:39.40 |
| mvrhel_laptop | well I see that | 18:39.45 |
| Robin_Watts | However, fz_page_s is not defined anywhere :) | 18:39.55 |
| mvrhel_laptop | right | 18:40.01 |
| | this is a little confusing to me | 18:40.13 |
| Robin_Watts | You just pass fz_page's back into the API. | 18:40.23 |
| | You shouldn't need to fiddle inside an fz_page yourself. | 18:40.31 |
| mvrhel_laptop | ok | 18:40.36 |
| Robin_Watts | (The code inside casts fz_page to pdf_page or xps_page etc, I think) | 18:40.59 |
| | Does that make sense ? | 18:41.32 |
| mvrhel_laptop | hold on. I am looking over what tor8 did in the ios app | 18:42.04 |
| Robin_Watts | is impressed. I can't even read Objective C without my head exploding. | 18:42.33 |
| kens | mvrhel_laptop : I'm making progress with the colour stuff as regards linework | 18:42.55 |
| mvrhel_laptop | Robin_Watts: ok. I think I see what I need to do. thanks! | 18:43.37 |
| kens | I have 9 files I need to investigate. THere are a number of chanegd files that are due to the shockingly bad state of the existing code, particularly as regards ps2write and /Separation spaces. | 18:43.38 |
| mvrhel_laptop | kens: ok. let me know if I am able to help at all | 18:43.59 |
| kens | At the moment its my own cod eI'm fixing, the colour CMS stuff is all OK | 18:44.15 |
| mvrhel_laptop | ok great | 18:44.24 |
| kens | OPnce I have the linework done I will move on to the images | 18:44.26 |
| | THis is *not* going to make thje release I'm afraid, at least not enabled by default | 18:45.00 |
| mvrhel_laptop | kens: right. it is getting close | 18:45.25 |
| kens | Yes too close, I may get it in but disabled and with a switch to flip to turn it on if anyone wants to experiment | 18:45.48 |
| | henrys, I see you asked too, same answer ;-) | 18:46.04 |
| | I had to rush off and make dinner | 18:46.20 |
| ray_laptop | Robin_Watts: thanks for getting involved with cust 532. If you want to chat with me we can do a private chat now. Back from the doctor. Still in pain, but not sure I want to take the hevay duty pain pills they prescribe (don't want to sleep all day) | 18:46.21 |
| henrys | ray_laptop:what happened? | 18:46.44 |
| kens | OK I am off now, goodnight all | 18:48.35 |
| ray_laptop | henrys: I don't know, but I did something to my neck and can't move it without a lot of pain, and even holding still hurts/ | 18:48.38 |
| | bye, kens | 18:48.41 |
| henrys | windows folks:so are ya'll using windows 8 without problems? thinking about a laptop with 8 this virtual box and vmware is just too pokey. | 18:49.38 |
| ray_laptop | if it persists, then they may do more exam. I've never had this before | 18:49.55 |
| | henrys: I am staying away from 8 as long as possible | 18:50.10 |
| henrys | ray_laptop:well I guess they checked for meningitis and you're clear of that. | 18:50.33 |
| mvrhel_laptop | ray_laptop: sorry to hear about your troubles | 18:50.59 |
| | if something urgent comes up that you need me for, let me know | 18:51.12 |
| | henrys: I have been happy with 8 other than the issues I had with vmware/hyperview. As long as you don't install the phone sdk vmware will be fine | 18:52.25 |
| henrys | using visual studio 2012? | 18:52.56 |
| mvrhel_laptop | henrys: yes | 18:53.38 |
| henrys | the laptops are pretty cheap I did read PC sales are declining | 18:54.15 |
| mvrhel_laptop | I actually just ordered a new laptop for my wife this week | 18:54.19 |
| henrys | what did you get? | 18:54.33 |
| mvrhel_laptop | Inspiron 15R Notebook (Inspiron 5521) | 18:54.55 |
| | My cousin works for Dell | 18:55.05 |
| | so I got it for a bit under $600 | 18:55.19 |
| Robin_Watts | (sorry, was on phone) | 18:56.09 |
| henrys | does he have insider info on the go private buyout ;-)? | 18:56.15 |
| Robin_Watts | ray_laptop: Ouch! My commiserations. | 18:56.15 |
| | ray_laptop: Are you on ibuprofen ? | 18:56.40 |
| | It can be very good for such things; reduces swelling etc. But I guess your doctor would have mentioned it... | 18:57.42 |
| mvrhel_laptop | henrys: good question. I see that this had a huge effect on their stock price. | 18:57.56 |
| Robin_Watts | henrys: What are you running the virtual box on ? | 18:58.58 |
| henrys | macbook pro | 18:59.13 |
| Robin_Watts | With lotsa memory? I'm surprised that you find vmware slow. | 18:59.36 |
| henrys | it seems to take me forever to compile which is all I care about - I give virtual box 4G | 19:01.05 |
| ray_laptop | Robin_Watts: sorry -- was working on bug '537. Yes, I am on ibufprofen. doesn't seem to do much, but maybe it would be even worse without it. | 19:01.28 |
| Robin_Watts | henrys: compile from where? a shared dir or a local one ? | 19:02.10 |
| henrys | the former is glacial and the latter slow | 19:02.24 |
| Robin_Watts | shared dirs are much slower (in VMware at least, can't comment on virtual box) | 19:02.32 |
| ray_laptop | in my experience, shared drives are REALLY slow | 19:02.37 |
| Robin_Watts | oh ass. 8.71 won't build for me. | 19:04.09 |
| | Looking at the customers files, I think the scan conversion is actually of glyphs, so 9.x will have different profiles as freetype takes the strain. | 19:06.57 |
| ray_laptop | Robin_Watts: oh, that's right. The Artifex font scaler has all of this crap for 'dropout prevention' when fill_adjust == 0. At 600 dpi, fill_adjust can be set to a non-zero number and avoid a lot of that overheadd | 19:26.59 |
| Robin_Watts | ray_laptop: Right. but they are calling spot_into_trapezoid_aj_fd which means they have fill adjust non zero, and fill direct. | 19:28.09 |
| ray_laptop | Robin_Watts: so that shouldn't be too slow. And if it is glyphs, don't they just get rendered to the cache, or is this a Japanese file where the cache is pretty useless ? | 19:30.46 |
| Robin_Watts | in the first file, under 9.06 I only see 10.65 seconds out of 53, in that routine and 10.36 is in the subroutines. | 19:31.17 |
| | It's a japanese file. | 19:31.24 |
| ray_laptop | Robin_Watts: sorry if I am not responsive. I'm trying to debug in another window | 19:31.37 |
| Robin_Watts | and of that 10.36 most of it is in pdf14_fill_rectangle | 19:32.00 |
| | and 3 seconds is a division in art_pdf_composite_pixel_alpha_8 | 19:35.02 |
| | ray_laptop: Are they at 600dpi or 300dpi? | 19:37.50 |
| ray_laptop | Robin_Watts: 600 | 19:38.24 |
| | Robin_Watts: who is calling pdf14_fill_rectangle ? the trapezoid logic or something else ? | 19:39.23 |
| Robin_Watts | I wonder if this comes down to pdf14 blending speed. | 19:39.27 |
| | The trap logic ends up calling into pdf14 to do the fill. | 19:39.38 |
| | I think their profiling is just crap. | 19:39.51 |
| ray_laptop | Robin_Watts: I agree that their profiling is funky. The simulator profile doesn't match the target, and the function names on the target profiles I've seen are not accurate (I think because they can't get the symbols right). | 19:44.33 |
| Robin_Watts | I got the impression that their profiling was done by them manually inserting stuff into the code. | 19:45.43 |
| | having said that very sleepy is messing around for me. I may be forced to use the 2010 team edition profiler. | 19:46.18 |
| | or 2008 team edition profiler, whichever one it was. | 19:46.31 |
| henrys | mvrhel_laptop: I also got cygwin working and I can run all the unix programs like git from the dos prompt.. I fear this will break in windows 8. From what I've heard it will break if I look at it wrong. | 19:51.42 |
| Robin_Watts | henrys: Is it possible that virtual box is just crap at disc access? | 19:52.22 |
| mvrhel_laptop | henrys: you are living on the edge | 19:52.23 |
| henrys | possibly I haven't give vmware a good try. | 19:53.19 |
| Robin_Watts | VirtualBox gets 7MBps, VMWare Fusion 5 gets 11.7, apparently. | 19:55.23 |
| | hmm. No. ray. | 20:41.35 |
| | What device should I be using to profile to most closely match the customers? | 20:41.57 |
| | cmyk or mono or even rgb ? | 20:42.19 |
| mvrhel_laptop | bbiaw | 21:19.11 |
| JamesMT | Whew, lots of James' on here. | 22:12.15 |
| | I do not suppose anyone could give me a hand getting MuPDF to compile? | 22:12.33 |
| | (Specifically the MuDraw project) | 22:12.45 |
| | Always have to wonder if Silence is a 'no' or a 'no one is around' :) | 22:15.08 |
| | Well, I am going to assume the latter for now and just explain my situation. I can not figure out which part of the OpenJPEG library I am supposed to be using, they have 4 selections from their lib folder and none of them contain all of the files referenced to in the MuPDF solution. | 22:18.35 |
| | And I just learned that submodule is an actual git command not just a reference to the third party libs. | 22:29.36 |
| tor8 | JamesMT: after you git clone mupdf, run "git submodule update --init" to check out the thirdparty stuff | 22:32.48 |
| JamesMT | Haha, Thanks tor8 I just finished that and it compiled smoothly for me :) | 22:33.06 |
| | Was just about to say Tata and head back into things.. Need to see if I can find why this one PFD is missing half its text when ran through MuPDF | 22:33.42 |
| | Thank you for taking the time however. | 22:33.57 |
| henrys | Robin_Watts: yeah a serial pcl compile is 50 seconds native and 3 minutes in virtual box - of course the windows and unix compiles are different so that may be part of it. | 22:34.55 |
| | wait let me double check that I think I made a mistake | 22:36.48 |
| tor8 | JamesMT: we may not always be prompt in answering, but we have logs so if you don't get an answer directly do stick around | 22:37.49 |
| JamesMT | tor8 Good to know, thanks again :) | 22:38.11 |
| henrys | yes 1 minute 42 native, that combined with the fact that clocks move slower on a windows machine makes it quite annoying. | 22:40.57 |
| | ;-) | 22:41.00 |
| JamesMT | I do not suppose someone can enlighten me to what the warnings messages I am seeing refer to ? cannot encode character with code point: 0 (54 times) and another for 0x6d00 (8 times) | 22:59.28 |
| | Forward 1 day (to 2013/01/16)>>> | |
IRC Logs