| | <<<Back 1 day (to 2011/07/19) | 2011/07/20 |
| Robin_Watts | night all | 00:16.30 |
| henrys | night | 00:16.43 |
| mvrhel2 | Is the polarity of the cups device correct in colorinfo when the 0 colorspace. tkamppeter? | 03:16.29 |
| | dev->color_info | 03:16.44 |
| | is it supposed to be additive or subtrative? | 03:16.55 |
| | subtractive... | 03:17.01 |
| | let me check CMYK and see what it does... | 03:18.53 |
| | argh! cab we no do away with #define cups((gx_device_cups *)pdev) | 03:21.27 |
| | and just use pdev in gdevcups.c | 03:21.44 |
| | s/cab/can/ | 03:21.52 |
| | s/no/not/ | 03:21.57 |
| | good grief. can I not type | 03:22.03 |
| | looks to me like the polarity is not getting set up correctly for these cups color spaces | 03:22.53 |
| | oh there it goes | 03:23.31 |
| | so CMYK polarity is getting set OK | 03:24.00 |
| | hmm according to the cups code CUPS_CSPACE_K should be subtractive, but when I am in the thresholding code it is not showing up that way | 03:34.25 |
| | something is mucking it up and I bet it is the pdf14 code.... | 03:34.55 |
| henrys | which bug is this? | 03:35.37 |
| mvrhel2 | oh hey the cups color space changed! | 03:37.01 |
| | this is the blocker | 03:37.10 |
| | 692074 | 03:37.25 |
| | so I specified cups space 0 | 03:37.38 |
| | which is the subtractive K space. | 03:37.47 |
| | and gdevcups.c sets it up correctly at first | 03:38.01 |
| | then during a get or set params it has changed the color space to additive W | 03:38.28 |
| | and so when I get to do the thresholding it is set to the opposite polarity on me | 03:38.50 |
| | very strange | 03:38.56 |
| | if you put a break point at cups->color_info.polarity = GX_CINFO_POLARITY_SUBTRACTIVE | 03:39.27 |
| | and at cups->color_info.polarity = GX_CINFO_POLARITY_ADDITIVE | 03:39.34 |
| | you will see it happen | 03:39.43 |
| | it is also nice to add in gx_device_cups *pdev_cups = (gx_device_cups *)pdev; into cups_set_color_info | 03:40.08 |
| | they have a macro #define cups ((gx_device_cups *)pdev) and use cups everywhere which is a pain in Visual studio | 03:40.35 |
| | I have half a mind to replace that devine with pdev_cups and do the above | 03:41.00 |
| | s/devine/define/ | 03:41.09 |
| | anyway. I have to get the kids to bed. I can get the correct output on this if I can get the polarity to be correct in color info. | 03:41.47 |
| | this is basically what I need to do for our planar device also. | 03:41.56 |
| | I have a fix in place that will switch the threshold call based upon the polarity. It basically does the same call but swaps the image data and threshold parameters in the call | 03:42.36 |
| | so that you have Image < threshold in one case and threshold < Image in the other | 03:42.54 |
| | easy enough | 03:43.01 |
| | but this cups color space is changing along the way which is causing me a problem. | 03:43.53 |
| | I may be back later tonight to dig more... | 03:44.05 |
| henrys | okay talk to you later. | 03:44.47 |
| mvrhel2 | oh I see CUPS_CSPACE_W is 0 | 04:14.34 |
| | which is an additive color space | 04:14.43 |
| | something odd is going on here though | 04:14.53 |
| | I see color space 0 is supposed to be gray in cups. color space 3 is black which is subtractive. | 04:17.38 |
| | ok. I have another way to take care of this... | 04:26.39 |
| | ok sure enough gx_device_white is 0 with pbmraw and 1 with cups | 04:31.52 |
| | and vice versa for gx_device_black | 04:32.07 |
| | just need to do a minor fix on the copy_mono | 04:32.47 |
| | henrys: so this should be easy to fix | 04:33.13 |
| | calling it an early night tonight though. I will fix this in the morning | 04:33.32 |
| kens | chrisl did you see the mail to support from Phil last night ? | 08:37.08 |
| | A216.pdf. | 08:37.24 |
| chrisl | kens: yes, I saw it | 08:38.40 |
| kens | There's a definite problem | 08:38.53 |
| | Its fonts and its not FreeType | 08:39.02 |
| | 8.71 has the same problem | 08:39.08 |
| | There is something very weird about the font matrices htough I think. | 08:39.25 |
| chrisl | Yep, I checked it enough to make sure it wasn't a regression, but I'm in the middle of pulling xfonts out, so I want to finish doing that. | 08:40.44 |
| kens | OK, in that case did you see henrys bug report about xfotns ? ;-) | 08:41.03 |
| | BTW I'm just reducing Phil's file. | 08:41.14 |
| chrisl | I did, Henry assigned both to me - not sure why we need to two bugs to track the problem....... | 08:41.40 |
| kens | Fair ebough then, you're on top if it. | 08:42.02 |
| chrisl | Oh, it looks like Henry took one of the bugs back again, I missed that! | 08:42.36 |
| kens | :-) | 08:42.45 |
| chrisl | The xfonts stuff is *crazy* complicated for what it does, I'm really not impressed with it. | 08:43.27 |
| kens | Interesting. Phil's file has hte text matrix rotated 90 degrees, but the text renders upright. I wonder how that happens.... Bet its related to the problem. | 08:43.33 |
| | chrisl another reason to lose it ;-) | 08:43.43 |
| chrisl | Absolutely! | 08:44.17 |
| kens | Off for a couple of hours back later. | 09:02.03 |
| chrisl | kens: (for when you get back) the problem (I'm fairly sure) with A216.pdf is that the WMode does not get copied from the CMap dictionary object in the PDF, to the CMap resource dictionary created from the PDF stream. | 11:22.19 |
| | going to lunch...... | 11:22.25 |
| nitin | i donn know whether i am doing it right or not... I have a query for you all, i am tryin to compile the muPDF source and not able to do it... please help me in providing me any possible clue or way to ahieve this | 11:57.23 |
| Robin_Watts | nitin: What OS ? | 11:59.05 |
| nitin | i am using windows and have got cygwin | 11:59.41 |
| Robin_Watts | nitin: Why not use MSVC ? | 11:59.53 |
| nitin | what is this? | 12:00.06 |
| Robin_Watts | Microsoft Visual C ? | 12:00.20 |
| | Visual Studio. | 12:00.28 |
| nitin | ok... is it easier with VS | 12:00.42 |
| Robin_Watts | It's what I use. | 12:00.51 |
| nitin | i need to compile the whole source tree as i need to use it in one of my android app... | 12:01.25 |
| | i need the .so file | 12:01.35 |
| | ok | 12:01.46 |
| Robin_Watts | Ah, so you want to build for android then, not windows. | 12:01.53 |
| nitin | yes | 12:02.00 |
| Robin_Watts | Right, different kettle of fish. | 12:02.09 |
| | In that case, get the source from git. | 12:02.23 |
| | The follow the instructions in the 'android' directory. | 12:02.38 |
| nitin | yes... i have got that | 12:02.39 |
| Robin_Watts | The android stuff builds a simple viewer. | 12:03.17 |
| | You'll almost certainly need to make changes to it, but it should point the way. | 12:03.41 |
| nitin | ya... | 12:04.01 |
| | i will make some changes but first thing is to compile the source tree... and m stuck here | 12:04.47 |
| Robin_Watts | ok, what stage of the instructions do you get stuck at? | 12:05.06 |
| nitin | i didn't follow the same available in the android folder | 12:05.34 |
| Robin_Watts | nitin? Sorry? | 12:06.43 |
| nitin | thanks for suggesting... let me try this way as well and if i am not successful then i will get back to this channel | 12:07.24 |
| Robin_Watts | ok. | 12:07.30 |
| nitin | thanks a lot | 12:07.31 |
| Robin_Watts | np. | 12:07.35 |
| nitin | hey Robin_Watts, it is the generated directory | 12:34.30 |
| | how to i get it???? | 12:34.38 |
| chrisl | kens: testing a fix for A216.pdf now | 12:34.42 |
| kens | that was quick chris ! | 12:34.51 |
| chrisl | It's pretty simple :-) | 12:35.03 |
| nitin | i am trying to compile the mupdf source but it is giving me some errors like "../generated/cmap_cns.h: No such file or directory" ... when i look back, the generated directory is empty | 12:37.11 |
| | please help me in fixing this... i have no clues | 12:37.27 |
| | i am using ndk and cygwin | 12:38.30 |
| chrisl | kens: should Phil's bugs be P1 or P2, do you know? | 12:40.16 |
| kens | I normally make customer bugs P2 unless htey are a crahs or regression. | 12:40.35 |
| | But, I am not really part of support.... | 12:40.55 |
| chrisl | No, you are awake just now ;-) Thanks! | 12:41.20 |
| kens | Ah, but they are a Very Importan Customer, so maybe P1 is appropriate | 12:41.39 |
| chrisl | Well, in this case, it's not going to make difference to how quickly it gets fixed! | 12:42.06 |
| kens | But you can claim it as a P1 fix :-) | 12:44.17 |
| | I assume this is the CMap WMode ? | 12:44.26 |
| | I was thinking that looked like a new one for me initially | 12:44.38 |
| chrisl | Yes, it is. I just realised my fix isn't quite right, need to be a bit smarter :-( | 12:45.35 |
| kens | Well, at least you know what the problem is. | 12:46.00 |
| chrisl | Yeh, it's just, that if there isn't a WMode, we don't want to create one. | 12:46.39 |
| nitin | please help me in getting the "generated" directory as what ReadMe.txt says in #8...i am still not able to get it | 12:46.47 |
| kens | nitin you ned either tor8 or Robin_Watts for MuPDF on Android | 12:47.19 |
| nitin | do i need to post these privately to them | 12:47.47 |
| | ? | 12:47.51 |
| kens | No, but if they are awayf rom their desk, then they won't be seeing your queries. | 12:48.19 |
| | I'm sure they will read the logs when they return. | 12:48.29 |
| nitin | oh... i see | 12:48.34 |
| | anyways thanks.. i am waiting for them to come back n reply | 12:49.18 |
| tor8 | nitin: compile mupdf natively first (for windows, with the makefile, or anywhere really), that will create a "generated" directory for you. | 12:49.23 |
| | the files in the generated directory are not platform specific | 12:49.57 |
| | so you can copy them from any build | 12:50.06 |
| nitin | ok... | 12:50.20 |
| | can u please help me lil further.... how to "copy them from any build"... i am a newbie in using native codes | 12:51.38 |
| | any guide or something | 12:51.55 |
| tor8 | compile mupdf for windows or linux. that will create a "generated" directory that you can use. | 12:52.20 |
| nitin | using gcc | 12:52.49 |
| kens | As I unserstand it, it doesn't mmatter what compiler you use. These are not object files, they are device independent files used by MuPDF. | 12:56.54 |
| | THey will later be compiled into MuPDF. | 12:57.14 |
| tor8 | exactly. the generated directory contains C source files that are generated from various font and character encoding files. | 12:57.55 |
| | Robin_Watts: osx lion was released today | 13:01.46 |
| Robin_Watts | back. | 13:07.32 |
| kens | tor8 I just sent you a text file. | 13:30.20 |
| Robin_Watts | tor8: We should put the generated directory up for download really. | 13:30.27 |
| tor8 | Robin_Watts: I'm not entirely comfortable with that, since sometimes the format of the files change (like when we were optimising the cmap data structures) | 13:31.31 |
| Robin_Watts | tor8: Right. But when we do a release, we do a thirdparty, and we should also do a generated. | 13:32.30 |
| tor8 | Robin_Watts: how much work would it be for the android build to be able to generate them when you run make? | 13:33.26 |
| Robin_Watts | I can update the android instructions to say "we provide a copy of the generated directory to download at each release. If the format changes between releases and you are getting your source from git, you will have to generate your own." | 13:34.10 |
| | tor8: using what compiler ? | 13:34.15 |
| | to do that we'd need a native compiler too. | 13:34.29 |
| tor8 | the android sdk only has a cross compiler? | 13:34.47 |
| Robin_Watts | tor8: the sdk only has a java compiler. the ndk only has a cross compiler. | 13:35.09 |
| tor8 | meh. | 13:35.22 |
| kens | chrisl when are you thinking of tagging/branching for release ? | 13:37.22 |
| chrisl | kens: I'm going to create the branch on Friday, barring strong complaints | 13:37.48 |
| kens | OK, I am hoping to have something vaguely functional in textwrite for inclusion. Its not risky, because it only affects a device which currently does nothing. | 13:38.23 |
| | I'll try and get it checked in on Friday | 13:38.40 |
| chrisl | kens: I can still cherry-pick it after the branch, it's not going to affect any existing functionality, after all | 13:40.37 |
| kens | Its not a problem I hope, I'd just liek to have something for people to look at in the release. | 13:41.03 |
| | Oh, two tors double the fun. | 13:45.14 |
| tor3 | kens: I'm about to upgrade my laptop, so tor8 will disappear for a bit | 13:45.43 |
| chrisl | bye-bye XFonts....... | 13:55.23 |
| kens | cheers | 13:55.36 |
| chrisl | :-) There'll be partying in the streets! | 13:55.57 |
| tor8 | \o/ | 13:58.34 |
| Robin_Watts | 3.5Gig of OS-X download. Joy. This'll keep my ADSL warm. | 14:18.04 |
| tor3 | kens: I'm looking at the captions.pdf textwrite output | 14:20.17 |
| | the missing bits of text are curious indeed! | 14:20.42 |
| kens | Its my fault, somewhere my consolidation is eating the text. | 14:20.56 |
| | I've had similar problems before, its prbably not hard to fix, once I can find t, it'll be a stupid logic flaw. | 14:21.22 |
| tor3 | it looks like the second column, or text after some odd horizontal spacing, is eaten | 14:21.41 |
| kens | I believe its when it decides it can't join text and issues a new y scan. | 14:22.06 |
| tor3 | possibly font change related, since most of the missing bits are the boldened headlines | 14:22.10 |
| kens | I don't care btou fonts, beyond noting the names ;-) | 14:22.25 |
| | Like I said, it'll be easy when I find it. At the moment I'm looking at the spacing in adobe.pdf because its worse there. | 14:22.53 |
| tor3 | the odd one out is the "Biology is a subject..." line | 14:22.58 |
| kens | Yes, there's something wrong with teh spacing there too. | 14:23.41 |
| | Of course, its never going to be perfect ;-) | 14:23.49 |
| tor3 | indeed. but it looks like a very good approximation at least :) | 14:24.27 |
| Robin_Watts | I hate garbage collection. | 14:24.30 |
| kens | tor3 overall I'm quite happy with that one. | 14:24.38 |
| tor3 | ARGH! they've reversed the two-finger multi-touch scroll direction! | 14:34.26 |
| | scrolling down scrolls up! | 14:34.35 |
| chrisl | that'll be to match smart phone touch screens | 14:35.06 |
| Robin_Watts | cancels downloads. | 14:35.27 |
| | tor3: That must be an option. | 14:35.42 |
| tor3 | stupid steve... I really really hope there's an option | 14:35.51 |
| chrisl | Why would there be an option? Apple is "right ", by definition! | 14:36.34 |
| tor3 | last step of the intall wizard: use multi-touch to scroll down to click the "next" button | 14:37.26 |
| | okay, found the option. uncheck "scroll direction: natural". | 14:38.09 |
| kens | See, you're un-natural :-) | 14:38.37 |
| tor3 | most definitely! :) | 14:38.43 |
| | they could've picked a better space background picture... this one is full of jpeg quantization artefacts | 14:39.20 |
| kens | Most people won't notice | 14:39.54 |
| | Or possibly think space looks like that anyway | 14:40.33 |
| tor3 | :) | 14:40.47 |
| | oh noes. they've gone and renamed "Airport" to "Wi-Fi" | 14:41.01 |
| Robin_Watts | Good. | 14:41.15 |
| tor3 | they're both stupid names. but at least wi-fi is universally recognised. | 14:41.46 |
| | wow, they finally gave up on the rounded buttons. they're definitely more rectangular now. | 14:42.58 |
| | if I was being mean I'd say it looks like vista :) | 14:43.22 |
| Robin_Watts | does the mvrhel2 summoning dance. | 15:09.13 |
| henrys | chrisl:might be confusing I assigned that bug to you so you would remove xfonts - I said in the other bug it was to be deprecated and we wouldn't investigate the problem. | 15:23.20 |
| chrisl | henrys: I understood in the end. Anyway, xfonts is gone now! :-) | 15:24.10 |
| henrys | yeah! | 15:24.17 |
| Robin_Watts | ray's next laptop? http://www.pcauthority.com.au/News/264208,two-screen-laptops-complete-overkill-or-completely-logical.aspx | 15:25.22 |
| chrisl | Robin_Watts: that would be great on the plane ;-) | 15:26.19 |
| kens | Yes, you could use your neighbours space too :-) | 15:26.49 |
| henrys | if you buy 2 seats | 15:26.58 |
| chrisl | henrys: I went to look at removing the lx5000 device but, erm, it seems to work now........ | 15:28.16 |
| henrys | I remember it worked for some resolutions. | 15:30.27 |
| chrisl | I followed the bug report | 15:31.53 |
| henrys | right I do remember it crashing and looking at the code and deciding I didn't know enough about the device to fix it. | 15:33.36 |
| | I'll try it too if I don't see it I'll throw it back to marcos - circle complete | 15:34.54 |
| chrisl | Cool, thanks. | 15:35.06 |
| henrys | I really thought shelly would find more fixes than that, we must be pretty good at closing what we fix. | 15:42.29 |
| Robin_Watts | I keep reading comments in the source (or maybe just one comment read multiple times) that says that once a pdf14 device is created it's never destroyed. | 16:09.09 |
| | It just gets reused again and again. | 16:09.15 |
| | If that's true, why do we have more than one of them ? | 16:09.27 |
| kens | I didn't know we did | 16:09.35 |
| chrisl | Pre and post clist? | 16:09.48 |
| Robin_Watts | No, I've got like 60 of 'em :) | 16:10.02 |
| kens | Not good.... | 16:10.14 |
| chrisl | Oops! That don't sound right | 16:10.21 |
| kens | Presumably something doesn't realise there is one, and makes a new one | 16:10.50 |
| henrys | chrisl:if the aes problem if phil's it's p1 and needs a customer number you can ping marcos to do it. But I don't want the bug to get buried. | 16:10.57 |
| | as low priority | 16:11.03 |
| | s/if/is | 16:11.17 |
| chrisl | henrys: I know, I just made it P1. | 16:11.26 |
| henrys | thanks | 16:11.32 |
| chrisl | In the "new bug" page, I don't get a priority menu, should I? | 16:12.13 |
| henrys | no priority, it seems we should have that though. | 16:14.01 |
| chrisl | Right, well that's why it's two steps (three, actually, as I can't seem to create private attachments on the new bug page either). | 16:14.48 |
| henrys | yes I should have waited a bit before saying something. | 16:17.04 |
| Robin_Watts | Aha. mvrhel2. | 16:17.51 |
| | Want to fetch coffee? You may need caffiene to help with the pdf14 questions... :) | 16:18.08 |
| chrisl | alexcher: ping? | 16:18.50 |
| mvrhel2 | morning Robin_Watts | 16:18.59 |
| | we can just dive in right now | 16:19.09 |
| Robin_Watts | I've been tracking the problems with stars.pdf. | 16:19.27 |
| | And they seem to come to the fact that we end up doing a garbage collection on a pdf14 device, which has a non zero target. | 16:19.56 |
| | but the target points to a freed block. | 16:20.03 |
| | so either we move into hyperspace or we scribble on freed memory etc. | 16:20.32 |
| mvrhel2 | the pdf14 device should never be remove once inserted | 16:20.33 |
| Robin_Watts | Right. | 16:20.39 |
| mvrhel2 | but should just pass along its compositor commands | 16:20.44 |
| Robin_Watts | So why do I have 60 of the buggers? :) | 16:20.47 |
| mvrhel2 | now in the case of the pattern we have a unique case | 16:20.54 |
| | the pdf14 device for the pattern should be done but not closed | 16:21.11 |
| | well I am not sure about that actually | 16:21.21 |
| Robin_Watts | 60 may be an underestimation. | 16:21.37 |
| mvrhel2 | hold on let me look at one thing in the code | 16:22.07 |
| Robin_Watts | When the pdf14 device is done with, we call pdf14_disable_device. | 16:22.23 |
| | Can I just set the target to be NULL in there? | 16:22.31 |
| mvrhel2 | yes that is what I was looking for | 16:23.29 |
| Robin_Watts | I've just (literally just) tested it, and that seems to work. | 16:23.50 |
| | Any call to recreate the compositor, will reset the target, so that should be safe. | 16:24.18 |
| mvrhel2 | I would not think the target would have been gc'd | 16:24.18 |
| | since you are running into a gc issue this must be during clist writing | 16:24.36 |
| Robin_Watts | See line 467 of gdevp14.c | 16:25.00 |
| mvrhel2 | ok. can't deny that | 16:25.16 |
| | yes. I would set that to NULL | 16:25.27 |
| Robin_Watts | For the 720dpi case at least, it's in the gc that's done just before exit. | 16:25.30 |
| | OK. I'll clusterpush and test that out. | 16:25.52 |
| | Thanks. | 16:25.58 |
| mvrhel2 | there is still something weird there | 16:26.16 |
| Robin_Watts | just *one* thing ? | 16:26.25 |
| mvrhel2 | hehe | 16:26.28 |
| | ok. I am going to fix my blocker bug now | 16:26.55 |
| Robin_Watts | mvrhel2: Thanks. | 16:29.52 |
| mvrhel2 | np. I don't think I was too much help though. | 16:30.05 |
| kens | Night all | 16:50.08 |
| Robin_Watts | stars.pdf seems to take 10 mins now (profile build rather than debug) | 16:50.26 |
| | night kens | 16:50.32 |
| kens | That sounds good | 16:50.37 |
| henrys | mvrhel2:i'd be incline to close 688638 we've made noises about creating a rop compositor but I doubt we'll do it. | 17:00.39 |
| mvrhel2 | ok | 17:01.34 |
| | are there real rendering issues that we need to worry about with respect to this though? | 17:01.47 |
| henrys | it's not as if compositors have been a "design coup" anyway. | 17:02.02 |
| mvrhel2 | hehe no | 17:02.09 |
| Robin_Watts | mvrhel2: Setting the target to NULL there provokes many SEGVs :( | 17:02.58 |
| mvrhel2 | ok. darn | 17:03.07 |
| | Robin_Watts: I am about to wrap up this blocker bug | 17:03.18 |
| | maybe I can help. | 17:03.22 |
| Robin_Watts | Thanks. | 17:03.31 |
| | This is all improving my knowledge of the pdf14 device, but I'd trade that for a quick fix :) | 17:03.54 |
| mvrhel2 | I need ray_laptop to do the commit on the icc_dir before I finish up my gray to K fix on the other bug that I want to get in 9.04 | 17:03.55 |
| henrys | right ... haven't heard from ray_laptop today. | 17:04.31 |
| mvrhel2 | I may give him a call. Is he going to add in the SMALL_ICC_PROFILES stuff for 9.04 also? | 17:05.18 |
| henrys | I'd like to know that also, I would switch the language to use small profiles if so. | 17:05.51 |
| mvrhel2 | yes. I had really wanted to get the "dumb" CMM in place too but that is not going to happen before the end of the month... | 17:07.40 |
| Robin_Watts | oh, damn. | 17:08.01 |
| | the device stays in place as a forwarding device. | 17:08.12 |
| | hence it has to keep target being valid. | 17:08.30 |
| | I think the problem may be that the compositor really ought to be destroyed when we're finished with it at the end of clist band playback. | 17:09.00 |
| henrys | early lunch be back in an hour or so. | 17:10.03 |
| mvrhel2 | I am bothered that we had no GC issues until we started fixing bbox issues. I don't understand how that could have caused this | 17:10.16 |
| Robin_Watts | mvrhel2: I think we probably did have such issues. | 17:13.10 |
| mvrhel2 | ok | 17:13.15 |
| Robin_Watts | just in the way of gcness, sometimes they don't show up. | 17:13.22 |
| mvrhel2 | I have seen that before | 17:13.45 |
| | oh henrys: I had a question I meant to ask you Tuesday | 17:14.48 |
| | did you ever hear back about bug 692183 and 692186? | 17:15.12 |
| | about the JPEG and TIFF writing of ICC profile | 17:15.24 |
| | I would like to get something back from them about the source of this code before we add it in | 17:15.48 |
| Robin_Watts | Right. We're getting a new pdf14 compositor device created on every clist_playback_band. | 17:22.24 |
| | There must be a way to kill that device at the end. | 17:22.43 |
| | If I'm understanding this correctly, we're currently relying on garbage collection to get the old compositors removed. | 17:26.13 |
| | Which really won't play nice with the other languages. | 17:26.25 |
| mvrhel2 | sorry I was on the phone with ray | 17:26.44 |
| Robin_Watts | np. | 17:26.49 |
| mvrhel2 | henrys: he seems to think we will be able to get the SMALL_PROFILE fix in for 9,04 | 17:27.02 |
| | Robin_Watts: so with the clist there is a compositor installed during writing that goes through GC. during playback there is no GC | 17:27.52 |
| Robin_Watts | That's not what I'm seeing here. | 17:28.16 |
| mvrhel2 | you are seeing GC during playblack? | 17:28.27 |
| | playback? | 17:28.30 |
| Robin_Watts | I believe so. | 17:28.37 |
| mvrhel2 | oh I guess I mean VMreclaim | 17:28.45 |
| | never happens during playback | 17:28.53 |
| Robin_Watts | or rather... I am seeing VMreclaim when the whole file is finished, and that destroys the compositor objects created during playback. | 17:29.30 |
| mvrhel2 | ok at the very end | 17:29.49 |
| Robin_Watts | So the gc doesn't happen during playback, but objects created during playback are gc'd. | 17:29.53 |
| mvrhel2 | yes | 17:30.05 |
| | can you send me a patch I can apply or publish a branch? | 17:30.32 |
| Robin_Watts | So, if I'm understanding this correctly we will 'leak' 1 compositor for every band until the file completes. | 17:30.44 |
| mvrhel2 | no I can show you where those are destroyed. or where they should be | 17:31.11 |
| | hold on | 17:31.17 |
| Robin_Watts | Ah, please... | 17:31.17 |
| mvrhel2 | I thought it is supposed to occur in gxclrast.c around in line 2139 | 17:33.16 |
| | remember this fun part of code? | 17:33.21 |
| Robin_Watts | oh, right. | 17:33.45 |
| mvrhel2 | hold on my clusterpush finished | 17:33.59 |
| | ok. cool only diffs in the cups device | 17:34.46 |
| Robin_Watts | I never liked that code :( | 17:34.57 |
| mvrhel2 | yes. | 17:35.25 |
| Robin_Watts | I would have preferred: if (target->r.ref_count == 1) { dev_proc(target, close_device)(target); } rc_decrement(target); | 17:35.43 |
| | because, AIUI, the rc_decrement does the free (and any required finalise) | 17:36.02 |
| mvrhel2 | yes I agree. Not sure why the test is needed | 17:36.48 |
| Robin_Watts | BUT... I'd have liked it even more if the close_device was done as part of the finalise - but I don't know the device procedures well enough to know if that's feasible. | 17:36.54 |
| mvrhel2 | oh you have to close it hgouth | 17:36.56 |
| | though | 17:37.00 |
| Robin_Watts | right, but my rejigging of the code given above is clearer, IMAO. | 17:37.19 |
| mvrhel2 | yes. that could stand some clean up | 17:37.21 |
| | but I fear trying to fix that is going to send us on a journey that we don't have time to complete before 9.04 | 17:37.54 |
| Robin_Watts | So, OK, this should free the compositors after each band. Let me try and see whether it is or not. | 17:38.07 |
| | right. | 17:41.12 |
| | In stars, I see clist_playback_band start, then a device_push happens and we create a compositor 253d6c8 | 17:41.43 |
| | then I get another call to clist_playback_band. | 17:42.13 |
| | and that exits without creating a compositor. | 17:42.20 |
| | and another call that likewise exits without creating a compositor. | 17:42.48 |
| | (same thing another 5 times) | 17:43.17 |
| | then we exit with target=253d6c8, and orig_target 2539440 | 17:43.44 |
| | target->rc = 7. | 17:43.56 |
| | so I think each of those sub calls to clist_playback_band are incrementing the reference count and not decrementing it, which means we're not destroying here, and hence running into the gc crash later on. | 17:44.54 |
| mvrhel2 | ah ok | 17:47.14 |
| | ok bmpcmp finishied.. | 17:48.12 |
| | hmmm are the bmpcmp results of cups inverted? | 17:49.37 |
| Robin_Watts | I don't believe so. | 17:51.30 |
| | Oh, certainly they can't be inverted in the sense that your results would suggest :) | 17:52.14 |
| | because both old and new versions are loaded by the same code. | 17:52.26 |
| mvrhel2 | well the file that I generated opened ok with rasterview. | 17:52.47 |
| | I need to double check | 17:52.52 |
| | I guess I should build bmpcmp | 17:52.57 |
| Robin_Watts | mvrhel2: If you disable your patch, does the file that you generate open ok with rasterview too ? | 17:54.04 |
| mvrhel2 | no | 17:54.12 |
| | well it is inverted | 17:54.17 |
| Robin_Watts | Ah, right. | 17:54.24 |
| mvrhel2 | give me a moment | 17:54.25 |
| Robin_Watts | Well, it's entirely possible that bmpcmp gets it inverted in that sense, yes, sorry. | 17:54.44 |
| mvrhel2 | visual studio doesnt like the lack of casting of the Malloc in bmpcmp | 17:57.00 |
| | Robin_Watts: can I send you a file to look at? | 17:59.02 |
| Robin_Watts | Sure. | 17:59.10 |
| | but honestly, I'd just assume it was bmpcmp at fault. | 17:59.22 |
| | When I wrote the code, I was aiming for being able to get recognisable diffs out. | 17:59.40 |
| | it wouldn't surprise me to find that I get the polarity wrong in at least some cases | 18:00.00 |
| | If you think it's a progression from rasterview, then it probably is. | 18:00.15 |
| mvrhel2 | I am having trouble seeing the output in bmpcmp | 18:06.21 |
| | I built it in Ubuntu | 18:06.28 |
| | and I am running it on the file that views ok on rasterview | 18:06.47 |
| | bmpcmp test.ras test.ras out\diff | 18:07.03 |
| | where test.ras is the cups raster file | 18:07.11 |
| Robin_Watts | Right, so there are no differences between a file and itself :) | 18:07.31 |
| | hence no output. | 18:07.44 |
| mvrhel2 | ugh | 18:07.48 |
| | ok | 18:07.53 |
| Robin_Watts | Sorry. bmpcmp is a dead simple thing thats designed to do *just* enough to let me have a perl script make the html pages you see. | 18:08.29 |
| mvrhel2 | maybe I have the wrong one laying around here | 18:08.30 |
| | I understand | 18:08.36 |
| | np | 18:08.37 |
| Robin_Watts | Just so I'm clear here... | 18:09.07 |
| | you've done a change that you expect should invert the images? | 18:09.20 |
| | and bmpcmp is showing them as being the wrong way around ? | 18:09.35 |
| henrys | mvrhel2:no response on either of those bugs. | 18:09.46 |
| mvrhel2 | I have fixed it so that rasterview shows the images correctly | 18:09.46 |
| Robin_Watts | and rasterview shows them correctly? | 18:09.58 |
| | Well, don't spend another second thinking about it. | 18:10.06 |
| mvrhel2 | well I want to double check though | 18:10.14 |
| Robin_Watts | It's bmpcmp at fault. | 18:10.16 |
| mvrhel2 | I was going to send you the file | 18:10.21 |
| | you can see if it views correctly with bmpcmp | 18:10.32 |
| Robin_Watts | how? :) | 18:10.46 |
| mvrhel2 | hehe | 18:10.50 |
| | hold on | 18:10.54 |
| Robin_Watts | I can look at it in a hex editor and check the color spaces etc. | 18:11.14 |
| mvrhel2 | let me run the file both with and without the fix | 18:11.59 |
| | I just want to make sure I did not make a mistake | 18:12.18 |
| | I will then look at the results with rasterview | 18:12.30 |
| | again | 18:12.32 |
| Robin_Watts | Can you put the file on casper ? | 18:12.41 |
| mvrhel2 | yes | 18:12.48 |
| | hold on | 18:12.50 |
| | http://www.ghostscript.com/~mvrhel/test_fixed.ras | 18:15.18 |
| | so that views correctly with rasterview | 18:15.35 |
| | henrys: ok. that is too bad | 18:16.25 |
| Robin_Watts | 72dpi | 18:17.26 |
| mvrhel2 | yes 72dpi | 18:17.31 |
| Robin_Watts | 612 x 792 pixels | 18:18.25 |
| | 1bpp | 18:18.44 |
| | colorspace 'gray' | 18:19.26 |
| mvrhel2 | I don't know why they call this space gray | 18:19.53 |
| | basically in gs the device_white and device_black for the cups device with this color space is the inverse of pbmraw | 18:20.46 |
| Robin_Watts | I support colorspace=0 and colorspace=3 | 18:20.53 |
| | which is gray and black. | 18:21.00 |
| | I bet one is positive and one is negative. | 18:21.07 |
| mvrhel2 | yes | 18:21.11 |
| | 0 is inverted | 18:21.19 |
| Robin_Watts | not in bmpcmp :) | 18:21.36 |
| mvrhel2 | ok. | 18:22.06 |
| Robin_Watts | would you be happier with a fix to bmpcmp ? | 18:22.37 |
| mvrhel2 | well yes, it would be great to have it show the correct way | 18:22.55 |
| | so you know that you had a progression as opposed to a regression | 18:23.15 |
| Robin_Watts | just a tick then. | 18:23.23 |
| | Done. | 18:25.22 |
| | Run a bmpcmp, and you should be sorted. | 18:25.30 |
| mvrhel2 | so on the bmpcmp syntax the first parameter will be the file on the left and the second will be the fill on the right | 18:25.36 |
| | I am just double checking manually here too | 18:25.51 |
| Robin_Watts | CRD | 18:25.57 |
| | Candidate, Reference, Diff is what you get on the html page. | 18:26.11 |
| | and I think the args are in the same order, because I have little imagination :) | 18:26.23 |
| mvrhel2 | ah | 18:28.44 |
| | ok | 18:28.46 |
| | so I ran bmpcmp (before your fix) with test_old.ras test_new.ras out\diff | 18:29.30 |
| | and the 0000 output is shown ok | 18:29.45 |
| | and 0001 is inverted | 18:29.55 |
| | rasterview shows test_old inverted | 18:30.05 |
| | and test_new ok | 18:30.11 |
| | let me update | 18:30.15 |
| Robin_Watts | Right, that sounds consistent with what I'd expect. | 18:30.24 |
| | It looks like gx_pattern_accum_alloc is being called, and that ups the reference count to the target. | 18:31.18 |
| | but then it never gets knocked down again. | 18:31.25 |
| | What's the counterpart to gx_pattern_accum_alloc ? | 18:32.17 |
| mvrhel2 | there is a finalize I think for the accumulator | 18:32.36 |
| | hold on | 18:32.38 |
| Robin_Watts | pattern_accum_close doesn't seem to get called. | 18:32.41 |
| mvrhel2 | why does my bmpcmp not work still locally | 18:33.18 |
| | after updating | 18:33.20 |
| | oh there it goes | 18:34.12 |
| Robin_Watts | phew. I committed without testing. You had me worried there :) | 18:34.32 |
| mvrhel2 | Robin_Watts: I am not seeing any differences | 18:35.38 |
| | in the bmpcmp results | 18:35.41 |
| | I thought I didnt get your commit, but I did | 18:35.52 |
| Robin_Watts | You've run a cluster based bmpcmp and you're still getting the old results ? | 18:36.21 |
| mvrhel2 | no I am running bmpcmp locally. oh shit need to rebuild it | 18:36.41 |
| | dumb | 18:36.43 |
| | sorry | 18:36.47 |
| Robin_Watts | np. | 18:37.03 |
| mvrhel2 | ok all is well | 18:37.06 |
| Robin_Watts | cool. | 18:37.11 |
| mvrhel2 | rerunning my bmpcmp on the cluster to check | 18:37.45 |
| Robin_Watts | mvrhel2: Can you have a quick look at gx_pattern_accum_alloc please? | 18:44.10 |
| mvrhel2 | Robin_Watts: I need to head out for a bit. Need to get kids from track camp | 18:44.14 |
| | oh yes | 18:44.22 |
| | hold on | 18:44.24 |
| | ok I am there | 18:44.44 |
| Robin_Watts | It's in two halves. the second half is the clist writer. | 18:44.47 |
| mvrhel2 | yes | 18:44.52 |
| Robin_Watts | and it does cwdev->finalize = NULL | 18:45.00 |
| | presumably that's wrong ? | 18:45.13 |
| mvrhel2 | I would think there should be some clean up there | 18:45.27 |
| | yes | 18:45.29 |
| Robin_Watts | ok, I'll play with that, thanks. | 18:45.37 |
| | go get your kids. | 18:45.41 |
| mvrhel2 | ok. ttyl | 18:46.05 |
| ray_laptop | I pushed the merged patches for the ICCProfilesDir change (to lib_ctx). My clusterpush was OK. | 19:38.01 |
| Robin_Watts | ok, stars.pdf down to 10 mins, with no crash. | 20:38.36 |
| | 2 minutes 7 seconds if we disable interpolation | 20:41.12 |
| ray_laptop | Robin_Watts: w.r.t. interpolation -- is that downscale or upscale ? | 23:21.05 |
| Robin_Watts | ray_laptop: in stars.pdf it's upscale. | 23:21.19 |
| | The 'shadings' behind the stars are actually scaled images. | 23:21.35 |
| | If you disable interpolation, it becomes obvious. | 23:21.43 |
| ray_laptop | wonders whether we should bother with interpolation when downscaling to contone devices | 23:21.45 |
| Robin_Watts | ray_laptop: For some things, absolutely, yes. | 23:22.02 |
| ray_laptop | Robin_Watts: what target res ? | 23:22.16 |
| Robin_Watts | nearest neighbour can cause terrible dropouts on some sources. | 23:22.39 |
| | 720dpi. | 23:22.46 |
| | gs/profbin/gswin32c.exe -r720 -sDEVICE=png16m -o out.png ../MyTests/stars.pdf | 23:23.14 |
| ray_laptop | I see. 720 dpi can be expensive, but not visible on real printers much beyond 180 dpi | 23:23.32 |
| Robin_Watts | Aha. | 23:24.03 |
| | mvrhel2: I committed a fix with a simple finaliser. | 23:24.20 |
| | and that seems to have done the trick. | 23:24.27 |
| mvrhel2 | I see that | 23:24.27 |
| | great! | 23:24.30 |
| | I see that you have the time down | 23:24.36 |
| Robin_Watts | yeah, release vs debug build. | 23:24.52 |
| mvrhel2 | nice way to end the day | 23:24.55 |
| ray_laptop | mvrhel2: have you had a chance to check COMPILE_INITS=0 ? | 23:24.57 |
| Robin_Watts | I have 491 diffs though, pretty much all in the cups device. | 23:25.18 |
| mvrhel2 | oh hi ray_laptop: no, I am testing my gray_to_k fix | 23:25.25 |
| | having the directory in the lib_ctx made life sooo easy | 23:25.38 |
| ray_laptop | mvrhel2: np. just curious. | 23:25.43 |
| mvrhel2 | ray_laptop. I will test it out now | 23:25.52 |
| Robin_Watts | mvrhel2: Did you have any idea why the cups device might be the only one to misbehave ? | 23:26.10 |
| mvrhel2 | Robin_Watts: no idea at all | 23:26.23 |
| Robin_Watts | When will your cups fix go in? | 23:26.39 |
| mvrhel2 | it already has | 23:26.45 |
| ray_laptop | doesn't really like pseudo-globals, but this does seem like the straightest path through | 23:26.49 |
| Robin_Watts | mvrhel2: Ah, cool. | 23:27.04 |
| mvrhel2 | the thing about this global is that it should not cause any MT issues | 23:27.20 |
| | hopefully different threads are not setting different directories | 23:27.39 |
| ray_laptop | Robin_Watts: cups has really strange modes, like RGB subtractive and CMYK additive and all kinds of screwy stuff | 23:27.41 |
| mvrhel2 | http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=b07cfe2e168d004ed1a4365e985d90c88fa61725 | 23:28.04 |
| Robin_Watts | mvrhel2: thanks. | 23:28.22 |
| | ray_laptop: Yes. I'm wondering if this points to something I'm doing wrong in the pdf14 stuff. | 23:28.40 |
| | like if we need colour conversion, maybe I can't restrict the bbox to just the dirty bit - maybe we have to do the whole buffer ? | 23:29.10 |
| ray_laptop | Robin_Watts: you are probably doing lots of stuff wrong in the pdf14 device ;-) | 23:29.12 |
| mvrhel2 | they have just been there all along | 23:29.36 |
| ray_laptop | mvrhel2: do any of the blend modes change any | 23:30.19 |
| mvrhel2 | Robin_Watts: no the transparency color spaces should all be their own thing between themselves. | 23:30.24 |
| ray_laptop | mvrhel2: do any of the blend modes change any 'unmarked' areas (I hope not) | 23:30.35 |
| mvrhel2 | that is, we should be only having CMYK subtractive, RGB additive and gray additive | 23:30.42 |
| | plus DeviceN which is a different thing all together and in which there are no group color spaces | 23:31.14 |
| | the conversion to the output device will happen during the putimage | 23:31.29 |
| ray_laptop | at least the pdf14 that way. And also Separations when in subtractive mode | 23:31.32 |
| | oops. typed too slow | 23:31.52 |
| mvrhel2 | ray_laptop: we should be skipping unmarked areas. There is some funny business though with respect to softmasks and the "background" setting which can have an affect outside the bbox of the softmask group. | 23:32.47 |
| | that is a real pain | 23:32.51 |
| | I believe we addressed those issues | 23:33.22 |
| | but I don't recall how..... | 23:33.27 |
| | I swear my memory isnt what it used to be | 23:33.43 |
| ray_laptop | I remember when my memory was better (so I guess my memory isn't totally non-functional) ;-) | 23:34.40 |
| mvrhel2 | :) | 23:34.52 |
| Robin_Watts | I wonder if its the softmask thing that I'm getting wrong. | 23:36.12 |
| mvrhel2 | a file that has the issue, iirc was the one with the euro symbol | 23:36.37 |
| | is that one coming up as a problem | 23:36.45 |
| Robin_Watts | Like maybe for softmask groups, I should set the dirty rectangle to be full rather than empty. | 23:36.55 |
| | don't know. will look when the bmpcmp finishes (and my windows PC wakes up again) | 23:37.09 |
| mvrhel2 | Robin_Watts: yes, you may want to try that to see if it makes a difference though | 23:37.20 |
| ray_laptop | occasionally I force myself to stop and recall when I otherwise might just 'grep' or look at logs or email -- just to keep my "chops". Also I don't use reading glasses, but work to read tiny print (at least tiny for my age) | 23:37.24 |
| mvrhel2 | bbiab | 23:39.06 |
| Robin_Watts | Hmm. | 23:42.42 |
| | The bmpcmp doesn't show any cups differences. | 23:42.56 |
| | Will check 'em manually tomorrow. | 23:48.46 |
| | Bedtime now. Night all. | 23:48.57 |
| ray_laptop | g'nite, Robin_Watts | 23:49.23 |
| | Forward 1 day (to 2011/07/21)>>> | |
IRC Logs