| | <<<Back 1 day (to 2011/12/08) | 2011/12/09 |
| mvrhel | henrys: I just pushed -dUseFastColor | 05:05.55 |
| | I need to have a cluster run the option on to check for segvs across the whole set of files. | 05:06.21 |
| | but it works in the files that I tested with which was pretty well varied as well as with devices | 05:07.15 |
| | it is a device parameter | 05:08.10 |
| | I need to see if it helps with bug 692674 | 05:09.01 |
| henrys | mvrhel:did you mean to check in the vc project file? | 05:12.21 |
| mvrhel | yes. there was one file | 05:25.00 |
| | oh | 05:25.02 |
| | crap | 05:25.04 |
| | hmm | 05:25.13 |
| | I need to double check where visual studio keeps its list of files for the ide | 05:26.05 |
| | hold on | 05:26.07 |
| | I may have done it in the wrong spot | 05:26.14 |
| | ok. so yes it was supposed to be checked in, but apparently some of the changes in it are wrong. let me fix that henrys | 05:29.04 |
| | this is the danger of running a different version of visual studio than the one that we use in the trunk | 05:30.21 |
| | or the one that we maintain for in the turnk | 05:30.32 |
| | ok that is fixed. Thanks for catching that henrys | 05:36.23 |
| | Robin_Watts would have wondered what happened to all his hard work on that file :) | 05:37.17 |
| | I guess I should have pushed that one as CLUSTER_UNTESTED | 05:37.31 |
| | shoot | 05:37.33 |
| henrys | no problem | 05:37.53 |
| | nobody else is here and my house needs heat. | 05:38.26 |
| mvrhel | :) How was your time in Miami | 05:38.39 |
| henrys | really good - we got to go an see the buffalo tiger guy. He took us out in the air boat and made this clicking noise and the alligators came to him like dogs. really something. | 05:39.46 |
| mvrhel | oh wow | 05:39.55 |
| henrys | then he would touch them on the snout and teeth - like an alligator whisperer ;-) | 05:41.10 |
| mvrhel | no way | 05:41.20 |
| | that sounds pretty cool | 05:42.06 |
| | I bet he would not have liked to see Miles grabbing that 12 footer by the tail | 05:42.24 |
| | probably was his favorite pet | 05:42.36 |
| henrys | then he took us out to an abandoned indian village and just let us off the boat onto this little boardwalk and a gator popped up at Sabrina and hissed at her, she very nearly jumped in the water. I imagine he loses a few customers ... | 05:43.38 |
| mvrhel | hehe | 05:43.48 |
| henrys | at the indian village he told us how the white settlers had poisoned his land and I thought oh christ he's going to leave us out here ... gator food... good adrenaline stuff.. | 05:45.16 |
| mvrhel | haha | 05:45.24 |
| | that is great | 05:45.28 |
| henrys | all in all a good trip I wish I booked the same time you guys did though - I did have a good dinner with most of the staff Saturday night. | 05:49.40 |
| | okay so this a device parameter, nothing special to add to PCL? | 05:51.10 |
| mvrhel | yes. It was good to see you and to meet Sabrina | 05:53.04 |
| | Yes it is a device parameter | 05:53.14 |
| | so I *think* it should work with pcl | 05:53.25 |
| | let me try it with xps | 05:53.43 |
| | I am not sure how much faster it actually is going to be (if at all) other than in the repeated startup and shutdown cases of that one customer. There are some problems with the current solution since it uses the device color mapping procs which operate with the frac values. So we do convert back and forth between those. I am thinking that if they procs are the defaults I may introduce... | 05:57.06 |
| | ...operations that avoid this conversion back and forth | 05:57.08 |
| | when I say problems I mean room for improvement | 05:57.34 |
| henrys | oh but I thought the profiling indicated all the time was in lcms doing the conversion. That much should be gone right? | 06:00.22 |
| mvrhel | yes. lcms does a bunch of conversion to generate the links | 06:00.51 |
| | as it is basically generating a table | 06:01.02 |
| | so for example, fill page will generate a table to map gray to the process colors | 06:01.20 |
| | it is done one time | 06:01.27 |
| | and then used after that | 06:01.38 |
| | but if you shut down and restart it has to generate the table again | 06:01.50 |
| | like wise if there was a cmyk fill to a rgb device | 06:02.06 |
| | it will generate the whole table | 06:02.12 |
| | now, this table generation will not occur | 06:02.26 |
| | instead we just grab the proper set of color mapping procs and those make up the "link" | 06:02.47 |
| | this is why when ray ran the customer's stuff as s server the slowness went away | 06:03.12 |
| | it is this initial creation of the tables that was killing it | 06:03.22 |
| | if the file takes .2 seconds to finish the table generation could be a decent part of that | 06:03.46 |
| | shut down and restart 1000 times it could add up | 06:04.10 |
| | one issue I had is that this link creation and table generation also occurs when we go out to pdfwrite | 06:04.50 |
| | which currently does not even use the result | 06:04.58 |
| | so with a fillpage we do the remap in graphics library (since the pdfwrite device's process color model is RGB by default) | 06:05.26 |
| | but the fillpage does nothing in pdfwrite | 06:05.34 |
| | but we end up generating a bunch of table samples in lcms | 06:05.57 |
| | that never get used | 06:06.03 |
| henrys | I was going to run it but it looks like you have to read some tome to get it set up. | 06:06.30 |
| mvrhel | oh so the device parameters are not availble in the other projects | 06:08.14 |
| henrys | no device parameters work fine. | 06:09.07 |
| | does it not seem to be working in xps? | 06:09.54 |
| mvrhel | yes it is working | 06:10.02 |
| | just ran it | 06:10.25 |
| | I wonder if I can get ray to do the timing tests for me | 06:10.50 |
| | I also want to do a cluster push with the -dUseFastColor option just to make sure there are no crashes | 06:11.09 |
| | with it | 06:11.11 |
| | I would be curious to see how pcl does with the option timing wise | 06:13.46 |
| | also, I do see where the CRD cache stuff is still getting set up. I will get that disabled | 06:14.38 |
| | I may tackle that tomorrow | 06:14.52 |
| henrys | I'll have a look tomorrow - I think you can assign that back to ray and focus on the crd stuff. | 06:15.00 |
| mvrhel | ok. I will do that thanks | 06:15.15 |
| tkamppeter | kens, thanks for the fix. I will test it. | 10:15.25 |
| kens | No problem tkamppeter, glad you saw the email | 10:15.36 |
| | henrys office should be nice and warm when he gets up :-) | 10:25.57 |
| tkamppeter | kens, your patch works, I will make an update for Oneiric with it. Thank you very much. | 10:40.01 |
| kens | No problem, always good to fix bugs. I have some other ones to look at but they don't seem to be affecting you yet. | 10:40.44 |
| tkamppeter | kens, tested also fix for bug 692612 and it works for me, too. Thanks for the hint. Will also get included. | 10:45.56 |
| kens | Ah yes, I do think its well worth including that one, Indexed colour spaces are quite common. | 10:46.39 |
| Robin_Watts | tor8: Did you add those files to that test.tgz ? | 10:52.44 |
| kens | Oh oh.... | 10:56.00 |
| | tkamppeter I would wait before sendong out that patch. | 10:56.13 |
| | The regression test has come back with some differences. WHich is annoying because I did one before committing and it was fine. | 10:56.36 |
| chrisl | kens: I think you need to put a longer string to contain the decimal number | 10:59.19 |
| kens | You oculd be right. But why didn't it show up on a regression test ? | 10:59.49 |
| | It is quite a reasonable length already, at 9 digits. | 11:00.25 |
| chrisl | But we can potentially be dealing with 4 byte GIDs, | 11:00.39 |
| | Oh, but those should be lopped off above that...... | 11:01.17 |
| kens | Indeed. Can't have numbers > 256 | 11:01.31 |
| | Have to go and test to see what's happening | 11:02.10 |
| chrisl | Hmm, <shrug> - it worked for the files I tested, although that was only a few files | 11:02.15 |
| kens | I did a cluster test and it was OK, then I updated to the master and committed. Now it shows differences :-( | 11:02.44 |
| chrisl | Well, you shouldn't be getting it with my latest (which does cause differences) because your commit was before mine | 11:04.41 |
| kens | I knkow, I'm puzzled. | 11:04.56 |
| | Uh. Looks like it *is* your changes. Do you have a list of which files changed ? | 11:07.12 |
| chrisl | http://www.ghostscript.com/cgi-bin/clustermonitor.cgi?report=chrisl | 11:07.47 |
| Robin_Watts | chrisl: Just read the commit message on your last commit. | 11:08.53 |
| kens | My results are identical except for 055-01.ps, 401-01.ps and 415-01.ps | 11:09.01 |
| | Looks like I'm seeing your changes chrisl | 11:09.13 |
| Robin_Watts | The default fill_adjust should be 0.5, not 0.3, but there is a hack in there for low res things. | 11:09.22 |
| chrisl | Oh, hang on, that can't be right, my commit shouldn't affect PS files | 11:09.26 |
| Robin_Watts | At low res, it sets a fill adjust of 0.3 or something. | 11:09.45 |
| chrisl | Robin_Watts: that's not really vital, the important thing is that it should be zero for glyphs *always* | 11:09.55 |
| Robin_Watts | fair enough. | 11:10.26 |
| chrisl | The change stores the current fill_adjust, sets it to zero, does the clip, and sets it back to what it was before - so the actual value is retained | 11:11.26 |
| | kens: maybe the cluster got confused about the order our commits happened. | 11:12.16 |
| kens | I think its possible, yes | 11:12.26 |
| chrisl | Do you want me to eyeball some of the differences? | 11:13.06 |
| kens | I've done that here, I've only looked at a couple, but they look like yours, it would be sueful if you would confirm though. | 11:13.36 |
| chrisl | Okay, give me a few minutes..... | 11:13.51 |
| kens | OK my source doesn't have your changes, and shows no differences in any of the files the cluster is complaining about. | 11:16.16 |
| chrisl | Those are definitely the differences caused by my commit | 11:22.40 |
| kens | Looks like it to me too. | 11:22.46 |
| | OK so panic over. | 11:22.50 |
| chrisl | Indeed | 11:22.55 |
| kens | tkamppeter, go ahead with the patch, the differences are explained now. | 11:23.04 |
| | More silly questions 'Can I make ps2pdf faster' ? | 11:28.45 |
| chrisl | Is that a customer? Not a name I recognise | 11:29.02 |
| kens | I think so yes. | 11:29.09 |
| chrisl | So: "yes, get a faster computer....." ;-) | 11:29.29 |
| kens | cusomer #73 | 11:29.40 |
| | Its tempting to make ti slower just so you can reply with 'yes, use the 'GoFaster' switch'.... | 11:30.14 |
| Robin_Watts | chrisl: So you're setting fill_adjust to 0 for the stroked parts of glyphs too ? | 12:53.47 |
| chrisl | No, just the clip | 12:59.22 |
| | Robin_Watts: ^^ | 12:59.37 |
| Robin_Watts | just when glyphs are used for clipping? Right. That sounds sane. | 13:01.13 |
| chrisl | Yes, exactly. | 13:02.36 |
| Robin_Watts | tor8: ping | 13:15.25 |
| tor8 | Robin_Watts: what sort of files are they looking for exactly? I have a collection of random specs and books that are "free" to redistribute if that's of use. | 13:17.31 |
| Robin_Watts | tor8: I think Miles has promised them a 'test suite' of 150 docs or so. | 13:17.59 |
| | so ideally we should have a range of files of different types that demonstrate a range of PDF functionality. | 13:18.28 |
| | The sane files seem like a good place to start to me. | 13:18.48 |
| | but that wasn't what I was pinging for - if you can add the 10 'fast sane' files that I've missed, I think we should be fine. | 13:19.23 |
| tor8 | right, so a collection of odd bug files from sane + some more book, newspaper and magazine type documents? | 13:19.25 |
| Robin_Watts | Sounds good to me. | 13:19.31 |
| tor8 | the fast sane is the set I showed yesterday | 13:19.41 |
| | I just dropped in zeniko's file ontop of that and it was still fast enough | 13:19.54 |
| Robin_Watts | I have the fast sane set here on my macbook. | 13:19.55 |
| tor8 | ah! are they part of the test.tar or different? | 13:20.11 |
| Robin_Watts | I couldn't immediately see them all in test.tar | 13:20.28 |
| tor8 | Robin_Watts: pastebin the file listing and I'll see if I can dig them up | 13:20.49 |
| Robin_Watts | 2.7.1colorpatch-devn_x1a.pdf amino130M.pdf | 13:21.25 |
| | 207ee6f24411fc4591d2b5a337c46de8-full.pdf dynalab.pdf | 13:21.27 |
| | Isolation-rgb.pdf page-content-array-segfault.pdf | 13:21.29 |
| | Isolation2-rgb.pdf pdfref17.pdf | 13:21.31 |
| | VOX.pdf tsm102.pdf | 13:21.33 |
| | actually, the Isolation ones are probably worth leaving out :) | 13:21.45 |
| | I was pinging because the context branch appears to be MUCH slower than the main branch for me. | 13:22.11 |
| tor8 | that doesn't sound good | 13:22.36 |
| | did you pull the patches I pushed last night? | 13:22.49 |
| Robin_Watts | but I'll keep looking at that, while you sort the test files, cos that's the priority. | 13:23.02 |
| tor8 | I got rid of the remaining fz_error_note places | 13:23.04 |
| Robin_Watts | Not yet, will do. | 13:23.05 |
| | Fab. | 13:23.07 |
| tor8 | and updated x11_main and pdfinfo to compile and run again | 13:23.25 |
| | still haven't touched the ios stuff | 13:23.31 |
| | but that shouldn't be a lot of work | 13:23.37 |
| | onto the test files | 13:23.43 |
| Robin_Watts | Oh! | 13:24.52 |
| | On the main trunk, we never free the xref, right? | 13:25.14 |
| tor8 | in pdfdraw? | 13:26.37 |
| Robin_Watts | actually, ignore that. | 13:26.51 |
| tor8 | Robin_Watts: oh, I tarred up the pristine zeniko set to send to casper! | 13:29.29 |
| | I have the files you listed here locally | 13:29.39 |
| | Robin_Watts, henrys: set of 150 pdf documents in /home/tor/pdf-suite-150.zip | 13:40.33 |
| Robin_Watts | tor8: Fab. | 13:41.04 |
| tor8 | Robin_Watts: I dropped in a few bigger files as well, including one of those horrible magazines full of full page color adverts. slow but it shows we can do complicated stuff as well. | 13:41.48 |
| Robin_Watts | tor8: cool. | 13:42.02 |
| | Ah, so the context branch has gone live on the main repo? | 13:45.00 |
| tor8 | Robin_Watts: yeah, but I didn't get the torrent of mail commit messages when I pushed it | 13:45.29 |
| | so I think we have a diff script for mupdf than ghostpdl | 13:45.39 |
| Robin_Watts | I got 1 email :) | 13:45.52 |
| tor8 | yeah, but it seems the branch creation mail got lost | 13:46.20 |
| | wonder if they'll all spew out when we merge... | 13:46.27 |
| | Robin_Watts: also, go ahead and give yourself commit access to the main repo | 13:47.17 |
| | I'll still be happy to review your commits before pushing if you want | 13:47.50 |
| Robin_Watts | tor8: Something seems not quite right with the mupdf repo. | 13:55.41 |
| | I was expecting master to be ba531f6 | 13:55.51 |
| | I think. | 13:56.40 |
| | I suspect that when the context branch got pushed, the master changes didn't ? | 13:57.23 |
| | (It's just a question of fast forwarding master) | 13:57.45 |
| tor8 | Robin_Watts: it looks like I haven't pushed master to casper main repo yet | 13:57.48 |
| | let me do that | 13:57.53 |
| | which is your 'master'? | 13:58.27 |
| Robin_Watts | My master is at ba531f6 | 13:58.46 |
| tor8 | robin/master is at 6e14149 | 13:58.50 |
| | tor/master is ba531fc | 13:59.07 |
| Robin_Watts | My mupdf repo may be screwed. | 13:59.10 |
| tor8 | right. tor/master seems to be the newest master at the latest merge into context | 13:59.32 |
| Robin_Watts | but the one on my local machine is (and the one on casper SHOULD be ) ba531f6 | 13:59.38 |
| | right. | 13:59.46 |
| tor8 | casper/master is now ba531f6 | 14:00.26 |
| Robin_Watts | perfect. My repo on casper should be right now too. | 14:01.05 |
| tor8 | yup. everything looks good to me now. except that there text branch which is horribly out of date :( | 14:02.09 |
| Robin_Watts | win_main.c line 366 | 14:03.43 |
| | Missing a " | 14:03.48 |
| tor8 | oops | 14:04.00 |
| Robin_Watts | Want to work some git magic to fix that? | 14:04.13 |
| tor8 | why don't you, since you're the one who found it ;) | 14:04.39 |
| Robin_Watts | I'll just commit the fix (not try and rewrite the history) | 14:04.56 |
| tor8 | that's fine | 14:05.04 |
| | the only one that's critical is pdfdraw so we can run regressions on any commit | 14:05.22 |
| Robin_Watts | ok, so I don't have commit access to the main repo. How do I fix that... | 14:06.23 |
| tor8 | ugh, it's been so long since I did this last time | 14:07.05 |
| | I think all we need to do is change the file permissions | 14:07.17 |
| | I'll try to do it | 14:07.46 |
| kens | Lots of MuPDF cluster tests queued, is that expected ? | 14:09.01 |
| tor8 | Robin_Watts: try now. | 14:09.25 |
| Robin_Watts | kens: Marcos must have reenabled that or something... | 14:09.51 |
| tor8 | kens: yeah, we just fast-forwarded the mupdf master branch with all of yesterday's work | 14:09.57 |
| kens | OK fair enough then | 14:10.06 |
| tor8 | but I wasn't aware that marcos had added mupdf to the regressions yet! | 14:10.11 |
| kens | THey are in the queue :-) | 14:10.21 |
| Robin_Watts | tor8: error: unable to create directory for ./logs/refs/heads/context | 14:13.49 |
| tor8 | Robin_Watts: I missed the top directory perms | 14:15.12 |
| | try again now | 14:15.14 |
| Robin_Watts | Bingo. | 14:16.12 |
| | lunchtime. | 14:26.49 |
| | I'm slightly confused by the master vs context speed differences. | 14:27.07 |
| | win32/Debug/pdfdraw.exe -d -o out.png ../MyTests/tor/pdfref17.pdf 1150 | 14:27.34 |
| | That takes 1 second on master, 10 on context :( | 14:27.45 |
| tor8 | ow. | 14:27.52 |
| Robin_Watts | but I get debug messages when it's writing the png on master, but not on context, so something isn't right. | 14:28.14 |
| | And the profiles aren't entirely helpful. | 14:28.29 |
| | Will try again after lunch. | 14:28.35 |
| henrys | chrisl:I guess the simplest thing to do is hang the pdf test suite off of ghostscript.com and then I (or you) can send Miles the link. | 14:37.01 |
| chrisl | henrys: is this a one-off, or do we want it permanently available? | 14:54.17 |
| henrys | I was just thinking of that myself | 14:54.47 |
| chrisl | If it's a one-off, it can just go in one our public_html dirs | 14:55.14 |
| henrys | yeah I'll just put it in mine, thanks. | 14:55.45 |
| chrisl | OKay cool, cheers | 14:56.59 |
| Robin_Watts | henrys: Your airboat ride sounded good. | 15:00.12 |
| | I think we went to the 'abandoned village' too. | 15:00.23 |
| henrys | the alligator there had babies and sabrina didn't see it -- she was the first off the boat and it really startled her when it hissed at her. I thought it was pretty close too but I guess the guide knew it would be okay - or not ;-) | 15:04.40 |
| Robin_Watts | We didn't see any babies :( | 15:07.27 |
| henrys | we have pictures I'll post them once sabrina lifts them off her camera. | 15:08.56 |
| | Robin_Watts, tor8:thanks for doing that I'll carefully read the contract to make sure nothing else unusual is promised. | 15:17.10 |
| Robin_Watts | tor8: Are you seeing the same slowdown? | 15:53.17 |
| tor8 | Robin_Watts: yeah. | 16:00.01 |
| | the per-page rendering time is fast though, 260ms for both master and context | 16:00.52 |
| | but total time is much slower | 16:01.01 |
| Robin_Watts | windows or macos? | 16:02.24 |
| | I tried removing the exception handling from within fz_fill_buffer, but it's still slow. | 16:03.15 |
| | I think it's the lexing time that's gone up, but I can't see why :( | 16:03.28 |
| tor8 | macosx | 16:04.57 |
| | and I'm having trouble understanding how the new "Instruments" profiler in Xcode 4 is supposed to work | 16:05.24 |
| | the old Shark was way way way better | 16:05.33 |
| | Robin_Watts: looks like fz_read_byte is making a syscall on every byte read :/ | 16:10.05 |
| | right, so every setjmp on macosx causes two syscalls | 16:15.30 |
| | sigaltstack and sigprocmask | 16:15.52 |
| Robin_Watts | Right, so that's in fz_fill_buffer | 16:16.40 |
| | Comment out the fz_try line and everything from fz_catch(... to } | 16:17.17 |
| | and does the slowdown go away? | 16:17.27 |
| tor8 | trying to nuke all fz_try setjmps see if that makes it fast | 16:18.13 |
| | and it makes no difference at all | 16:18.54 |
| | okay, it's twice as fast but still dog slow | 16:20.02 |
| | need to pop out for dinner, holler if you find it | 16:20.13 |
| Robin_Watts | will do. | 16:20.19 |
| tor8 | the profile still says it's in fz_read_byte | 16:20.23 |
| Robin_Watts | That change makes no difference at all on windows :( | 16:20.46 |
| | In fact avoiding all the setjmp calls makes no difference. | 16:22.25 |
| | OK. Nobbling the fz_try/catch completely doesn't solve anything for me. | 16:28.32 |
| sebras | Robin_Watts: running callgrind on it I see that you have about 5x the amount of cache-misses... | 16:30.19 |
| Robin_Watts | on macos? | 16:30.49 |
| | linux, presumably. | 16:30.56 |
| sebras | yes. | 16:30.59 |
| | I'm testing on pdfref14.pdf pages 1-10 to make it sufficiently fast. | 16:31.15 |
| Robin_Watts | Change fz_try to be: | 16:31.38 |
| sebras | I see 976000 calls to fz_read_byte() from master and 7460000 calls to it from context. | 16:31.41 |
| Robin_Watts | Really? | 16:31.57 |
| | That would explain it. | 16:32.00 |
| sebras | mmm. | 16:32.05 |
| Robin_Watts | Then the fz_try/fz_catch things are a red herring. | 16:32.19 |
| | what did I break... | 16:32.24 |
| sebras | :) | 16:32.28 |
| | pdf_open_xref() used to take about 5% of the execution time and on context it takes 77%... | 16:33.54 |
| Robin_Watts | indeed, that's exactly what I'm seeing. | 16:34.12 |
| sebras | pdf_load_object() seems to be called 31700 times, while it wasn't called at all on master.. | 16:34.45 |
| | same with fz_push_try()/fz_drop_obj()... | 16:35.03 |
| Robin_Watts | Oh. I bet I'm repairing every time or something. | 16:35.18 |
| sebras | yes, that would it. | 16:36.23 |
| | on context you always end up going through the for-loop trying to find root/info... | 16:38.59 |
| | on master you only do that if repaired is set... | 16:39.19 |
| Robin_Watts | yeah, I cocked up indenting things. | 16:40.22 |
| | Much better :) | 16:41.02 |
| sebras | cool. :) | 16:42.07 |
| | lazy day at work for me.. ;) | 16:42.14 |
| Robin_Watts | ok, context branch updated with fixed (not slow) patch. | 16:52.52 |
| mvrhel | Robin_Watts: question for you | 17:06.50 |
| henrys | alexcher are you around? | 17:06.56 |
| mvrhel | do you know a way that I could do a cluster run to test if -dUseFastColor has any segvs? | 17:07.23 |
| henrys | hardwire it on in the code and push? | 17:08.12 |
| Robin_Watts | mvrhel: What henrys said is certainly one option | 17:08.30 |
| mvrhel | oh yes. I could just make the default true | 17:08.48 |
| | duh | 17:08.50 |
| | ok | 17:08.53 |
| Robin_Watts | In fact it's the only option I can think of at the moment. | 17:09.05 |
| henrys | Robin_Watts:when you have a chance have a look at 688387 make it bountiable and see what you think of olavi's work. - I think this bug should go to you not alexcher. We are looking at him as a potential marketing/engineer position. | 17:11.15 |
| Robin_Watts | henrys: will look now. | 17:11.46 |
| mvrhel | bbiab | 17:13.21 |
| Robin_Watts | henrys: My gut feeling is that the approach he's taken is wrong. | 17:19.19 |
| | What he's done will work when masks are 'flipped' horizontally or vertically from the image to which they apply to. | 17:20.32 |
| | It won't cope with rotated cases. | 17:20.55 |
| | (and it's entirely possible that the underlying gs code won't either) | 17:21.17 |
| | I suspect that what Adobe does is to generate the matrix for the mask from the matrix for the image, but with a scale thrown in there to allow for the different width/height. | 17:22.15 |
| | Now, I could waste some time verifying this, but as it's to be a bountiable bug, I suspect I should push the extra investigation back onto him? | 17:23.01 |
| henrys | right ... | 17:23.20 |
| Robin_Watts | I'll write a reply asking him to do a bit more investigation. | 17:24.00 |
| henrys | Robin_Watts:don't get too used to management it rots the brain. | 17:29.28 |
| Robin_Watts | My hair isn't pointy enough. | 17:29.51 |
| | and my brain is rotting quite fast enough, thanks :) | 17:30.11 |
| mvrhel | shoot kens is gone | 17:53.11 |
| | I meant to ask him a pdfwrite question | 17:53.24 |
| | I am wondering if pdfwrite ever uses the CRD for any of its color conversions | 17:53.51 |
| Robin_Watts | henrys: I've been digging through the email to and from company number 8 from the agenda. | 17:55.21 |
| | It looks like I got gs ported to their board (not hard, it's just running ubuntu). | 17:56.27 |
| henrys | yes for some reason I was thinking that ball was in your court but I might have missed some message. | 17:56.37 |
| Robin_Watts | I was then supposed to look at profiling, but seem never to have gotten around to it. | 17:57.00 |
| | Partly cos planar took over my life, but partly because I'm not sure what exactly I'm aiming for. | 17:57.27 |
| | What's the goal here? | 17:57.34 |
| | If it's to show that gs can run happily on their board, well, we're there. | 17:57.48 |
| | If it's to squeeze every available ounce of performance from it... well, that probably needs me to be using a specific OS etc to be useful, rather than a random ubuntu image I got from the web. | 17:59.02 |
| henrys | Robin_Watts:I'm catching up on the email. | 18:01.07 |
| mvrhel | hmm so it appears that pdfwrite just does its own conversions | 18:02.14 |
| henrys | maybe it's a job for Scott he likes to talk to push these guys, did you want to handle it directly? | 18:04.06 |
| Robin_Watts | henrys: Not particularly. | 18:04.21 |
| | I kind of feel that without a defined goal, spending more effort on it is a waste of time. | 18:04.46 |
| mvrhel | sounds like they should evaluate what you have | 18:05.02 |
| Robin_Watts | We've done the important first step (make it work), and unless we have a specific target (certain number of pages per minute, or ability to drive a given printer or something) it's hard to see where to go now. | 18:05.39 |
| henrys | he did specifically say linux 2.6 I assume you have that. | 18:05.46 |
| Robin_Watts | I assume so. | 18:06.00 |
| | Yes, I'm using Ubuntu 11 or 11, and that's a linux 2.6 kernel. | 18:07.10 |
| | 10 or 11. | 18:07.13 |
| | Let me write an email apologising for dropping the ball, restating where we are, bringing scott back into it, and asking if we have an agreed target? | 18:07.45 |
| henrys | okay | 18:08.09 |
| mvrhel | cool. henrys. So it appears that with -dUseFastColor, bug692451 is fixed since I am using the UCR/BG stuff with this option | 18:20.42 |
| | the user included a neat ps file to test things out | 18:21.13 |
| | neat to beat on my seg faults. looks like the sep device has some issues with this option on | 18:24.52 |
| henrys | fixed or a workaround - do we want bg and ucr to work in the icc flow? | 18:24.58 |
| mvrhel | henrys: no we dont want them in the icc flow | 18:25.22 |
| | distiller does not make use of them either | 18:25.43 |
| | in the icc flow ucr and bg are handled by the icc profiles | 18:26.16 |
| | it is a much better way | 18:26.32 |
| | and what everyone really does | 18:26.47 |
| henrys | well yeah I agree it is better wanted to make sure we are doing what adobe does though. thanks | 18:27.12 |
| mvrhel | so yes, by default with gs we match adobe | 18:27.42 |
| | to get the old gs rendering one can do -dUseFastColor | 18:27.57 |
| Robin_Watts | I'm off out to dinner in a bit. will be back later. | 18:29.41 |
| mvrhel | hmm. release crashes but not debug build. my favorite! | 18:41.32 |
| henrys | bbiaw | 18:44.20 |
| Robin_Watts | mvrhel: try a profile build? | 18:45.05 |
| mvrhel | that is a good idea | 18:45.14 |
| | ok. that caught it! | 18:47.53 |
| | thanks Robin_Watts | 18:48.05 |
| Robin_Watts | fab. | 18:48.06 |
| | np. | 18:48.10 |
| mvrhel | hmm this is a messy one. mix-up on the devn member variable with device casting in the remap when we have the pdf14 device installed | 20:07.53 |
| | taking a break for a bit from this | 20:08.40 |
| Robin_Watts | back. | 23:13.12 |
| | Forward 1 day (to 2011/12/10)>>> | |
IRC Logs