| | <<<Back 1 day (to 2013/11/07) | 2013/11/08 |
| AdamL | Hi all.. Ray had given me some good advice earlier on how to combine a threshold with a BN dithering function | 01:24.30 |
| | i took that advice and generated a working command as follows: | 01:25.09 |
| | /usr/bin/gs -q -dSAFER -dNOPAUSE -dBATCH -dUseCropBox -sOutputFile=HYBRID_%d.tif -r300 -dDITHER=300 -sDEVICE=tiffg4 -Ilib stocht.ps -c "{ dup .5 lt { pop 0 } if } settransfer" -f $FILE | 01:25.10 |
| | which takes anything that's got a value darker than the threshold (0.5) and sets it black | 01:25.40 |
| | otherwise, apply dithering | 01:25.47 |
| | now, what I'd like to do is modify this slightly | 01:25.58 |
| | so that I have the same behavior, but that dithering only gets applied to things between 0.5 and 0.7 | 01:26.17 |
| | so that anything lighter than 0.7 just goes white | 01:26.29 |
| | is this an appropriate command? | 01:26.37 |
| | /usr/bin/gs -q -dSAFER -dNOPAUSE -dBATCH -dUseCropBox -sOutputFile=HYBRID2_%d.tif -r300 -dDITHER=300 -sDEVICE=tiffg4 -Ilib stocht.ps -c "{ dup .5 lt { pop 0 } if dup .7 gt { pop 1 } if } settransfer" -f $FILE | 01:27.13 |
| | (i'm a postscript programming novice, so i'm not sure if I've got the stack idea correct here) | 01:27.37 |
| | anyone ? | 01:45.15 |
| | hello ? | 01:52.15 |
| | i'm mostly having trouble with the RPN style notation of postscript | 02:18.38 |
| | hello | 03:42.13 |
| | anyone here ? | 03:42.16 |
| | hi marcosw | 03:46.52 |
| ray_laptop | yuck! The debug build works, but a profile build and the release build get a "Can't find (or can't open) font file GothicBBB-Medium-RKSJ-H. | 06:12.09 |
| | I *HATE* these kind of bugs. And with the ppmraw device, it works fine. Only fails with the xxx-aps device (cust 801) | 06:13.10 |
| | hmm... it only happens after outputting the 1st page. Clearly somebody is stomping on memory | 06:16.05 |
| sebras | ray_laptop: can valgrind help you? | 08:33.34 |
| | yey for mupdf! | 11:02.59 |
| kens | ?? | 11:03.13 |
| UhWhatever | Aloha | 11:05.56 |
| kens | Hol, Hi hao, buenos dias... | 11:06.26 |
| sebras | kens: I'm having a debate with colleagues at work about changing code in all places to be consistent, or just in the place a particular bug happened and make the code inconsistent. | 11:06.30 |
| UhWhatever | I got a question concerning MuPDF | 11:06.32 |
| sebras | UhWhatever: don't ask to ask, just ask. | 11:06.40 |
| UhWhatever | Ok. Is there an Appcelerator Module that uses MuPDF? | 11:07.34 |
| kens | has no idea what one of those is | 11:09.14 |
| | sI htink the answer to that is a resounding 'no', unless someone has built one and not mentioned it to us | 11:12.12 |
| UhWhatever | Ok. Thanks for the info! | 11:13.50 |
| Robin_Watts | Appcelerator is an "anyone can write apps" thing. | 12:34.17 |
| | Write once, will run on ios or android etc. | 12:34.28 |
| tor7 | Robin_Watts: emscripten+js+html5 or a cross-platform toolkit? | 12:40.56 |
| Robin_Watts | tor7: pass. | 12:41.21 |
| tor7 | paulgardiner: BTW, the ios developer account we're using is due to expire in two weeks | 12:41.46 |
| Robin_Watts | I spoke to them at AppsWorld last year(?) and tried to interest them in MuPDF, but they weren't particularly interested. | 12:41.52 |
| tor7 | paulgardiner: so if you feel we're in good shape to ship a new release to the appstore soon, maybe we should consider doing something about that before it disappears | 12:42.52 |
| Robin_Watts | tor7: We should renew the developer account before it expires. | 12:46.09 |
| tor7 | we talked briefly about making it a company account rather than one tied to me | 12:46.37 |
| Robin_Watts | Can you imagine the grief that will be caused by changing accounts with existing products? | 12:47.09 |
| | Possibly when we renew we'll get the change to upgrade to a company account. | 12:47.24 |
| tor7 | that's what's held us back so far :) | 12:49.56 |
| paulgardiner | tor7: Might be worth releasing a new version. It has forms and reflow now. I still have a way to go for annotations. And there is no javascript yet. | 12:55.29 |
| tor7 | paulgardiner: and I assume the glitches with ios7 have been fixed? | 12:55.46 |
| | the way the page jumps up and down when you toggle the toolbars | 12:56.01 |
| | oh, and did you make a patch to use all custom icons and not the horrible ios7 system ones? | 12:56.49 |
| paulgardiner | Oh ah. | 12:56.51 |
| | It's using the better icons, but I've done nothing about the glitches. I wasn't aware of them (although you probably told me). I've been putting off updating my ipad to 7 so as to be able to test all the new stuff on 6. | 12:58.32 |
| | Robin_Watts, sebras: endptr commit is on paul/master | 13:03.03 |
| tor7 | paulgardiner: ah! I expect you should be able to try ios7 in the simulator though? | 13:05.31 |
| paulgardiner | tor7: oh possibly | 13:07.03 |
| tor7 | hm, did someone break casper? git:// is down | 13:39.02 |
| kens | It wasn't me... | 13:39.25 |
| | I can login to casper | 13:40.22 |
| tor7 | ssh works fine, but the git server is not responding | 13:40.40 |
| kens | Mayeb the server daemon died | 13:40.57 |
| tor7 | kens: yeah. http access also works. | 13:41.19 |
| kens | has exhausted useful responses | 13:41.46 |
| chrisl | Seems to be working okay for me | 13:42.44 |
| Robin_Watts | Urgh. | 13:45.25 |
| | gs invocation on ../ghostpcl/tests_private/pdf/sumatra/586_-_non-white_background.pdf fails. | 13:45.55 |
| | same invocation on that file copied to 586.pdf in the current dir works fine. | 13:46.12 |
| chrisl | fails how, what platform? | 13:46.53 |
| Robin_Watts | windows. segv. | 13:47.13 |
| | memory corruption. | 13:47.20 |
| | also the cluster fails too. | 13:47.29 |
| tor7 | chrisl: git clone git://git.ghostscript.com/mupdf.git | 13:47.33 |
| | Cloning into mupdf... | 13:47.34 |
| | fatal: read error: Connection reset by peer | 13:47.34 |
| Robin_Watts | I've got 2 SEGVs left in the cluster tests. | 13:47.45 |
| chrisl | tor7: Oh, how strange - I updated a few minutes ago, and it worked | 13:48.59 |
| Robin_Watts | chrisl: Why would you have been using git:// ? | 13:49.33 |
| chrisl | Robin_Watts: I keep a git:// repo 'cause people sometimes ask about it on here - I can use it and say "it works for me"..... | 13:50.27 |
| Robin_Watts | ah :) | 13:50.35 |
| tor7 | Robin_Watts: I have all my fetch remotes configured as git: because it's way faster than ssh for fetchingn | 13:50.54 |
| | (and I'm too lazy to setup ssh-agent) | 13:51.19 |
| Robin_Watts | pageant, ftw. | 13:52.10 |
| | also, I can't remember if I've suggested it on here, but windows users may want to consider kitty instead of putty. | 13:52.31 |
| tor7 | Robin_Watts: what are the benefits of kitty over putty? | 13:53.16 |
| Robin_Watts | http://kitty.9bis.net/ | 13:53.46 |
| kens | home page has a comparison as I recall | 13:53.48 |
| Robin_Watts | It's the latest putty +various new features (mainly usability) | 13:54.29 |
| tor7 | chrisl: there are a dozen or so idling git-daemon processes... maybe something's deadlocked? | 13:54.50 |
| chrisl | Possibly.... | 13:55.27 |
| tor7 | and a ton of git-upload-pack | 13:55.39 |
| sebras | I got caught as well. :-/ | 13:55.40 |
| tor7 | anyone object if I kill the processes to see if things clear up? | 13:57.22 |
| chrisl | Hmm, dunno how to restart git-daemon :-( | 13:57.29 |
| tor7 | (or should I wait for marcos) | 13:57.31 |
| Robin_Watts | tor7: If it's not working at the moment, then we lose nothing by you killing the processes, right? | 13:58.23 |
| tor7 | Robin_Watts: no, but I'm not sure what our policy is regarding sysadmin stuff. | 13:58.58 |
| | chrisl: I think it's one of those inetd started things | 13:59.21 |
| chrisl | tor7: it used to /etc/init.d/git-daemon but that's not there now..... | 13:59.49 |
| Robin_Watts | tor7: I thought our policy was that I could break stuff and Marcos or Chris would tidy up after me? :) | 14:00.06 |
| chrisl | Robin_Watts: if that's the policy, I might take the afternoon off..... | 14:00.31 |
| tor7 | chrisl: well, killing them all off now lets me connect again | 14:00.54 |
| chrisl | Sounds good :-) | 14:01.06 |
| tor7 | makes me worried that it clogged up with stuck git-upload-pack processes though | 14:01.11 |
| chrisl | We'll just have to keep an eye on it | 14:02.01 |
| tor7 | paulgardiner: is the endptr thing not just a "tail" to go with the head? | 14:07.00 |
| paulgardiner | tor7: a sort of, although it's a ** | 14:08.02 |
| tor7 | paulgardiner: the api is starting to smell, when the simple linked list is no longer a simple linked list. better change it to something else, IMO. | 14:09.06 |
| | like an explicit tail queue, or a dynamically resized array, or a circular doubly linked list | 14:09.46 |
| Robin_Watts | tor7: It is a simple linked list. It's just a simple linked list with a pointer to the pointer that points to the last record. | 14:09.48 |
| tor7 | Robin_Watts: a tail queue :) | 14:10.04 |
| paulgardiner | A pointer to where the next record would go | 14:10.26 |
| Robin_Watts | paulgardiner: Yes. | 14:10.39 |
| paulgardiner | Where to extend from | 14:10.43 |
| tor7 | I'd wrap those in a struct of its own though, rather than let the api deal with two pointers | 14:10.50 |
| Robin_Watts | paulgardiner: Yes, my description was bad. | 14:10.55 |
| paulgardiner | I didn't think I'd changed the api | 14:11.17 |
| | tor7: if you don't like this, it might be best to leave it as is because the iteration required during create is unlikely to be a issue | 14:11.46 |
| tor7 | paulgardiner: and now it looks like the pdf_annot_xxx functions are tightly coupled with the pdf_page struct | 14:11.48 |
| | so I'd swap some argument orders | 14:11.54 |
| | s/endptr/tailp/ and put the pdf_page argument earlier in the signatures: pdf_load_annots(doc, page, annots) and I'm happy | 14:12.38 |
| paulgardiner | Oh okay | 14:13.00 |
| tor7 | I don't mind having a tail pointer, but I would like to develop an idiom for it that we use | 14:13.35 |
| paulgardiner | Is it a tail pointer? | 14:13.44 |
| tor7 | and one where it isn't easy to accidentally forget to update one of the pointers | 14:13.52 |
| | it's a pointer to where the tail will go, right? | 14:14.17 |
| | as opposed to the real tail (which would be named just "tail", the p on the end is for the ** nature) | 14:14.34 |
| paulgardiner | I think of "tail" as meaning everything but the first, but that's probably picked up from functional programming. | 14:15.27 |
| | But I'm happy to go with that. So annottailp? | 14:18.18 |
| tor7 | paulgardiner: right. feel free to use last rather than tail then :) | 14:20.25 |
| | annot_tailp or annots_lastp maybe with an underscore? | 14:20.47 |
| paulgardiner | Yeah underscore better, but I think I'd stick with tail | 14:21.26 |
| | tor7: updated as requested on paul/master | 14:33.17 |
| henrys | paulgardiner: we'll talk more tuesday about LO and other choices and let's double check for other solutions out there in the meantime, but I think we've hit all the possibilities in the open source community | 14:38.20 |
| paulgardiner | henrys: Yeah. The smartoffice code would probably be best if that comes off, but failing that I don't know between fighting LO or doing our own from scratch. | 14:39.43 |
| Robin_Watts | Just spoke to the administrator for SOT. | 15:01.52 |
| kens | SOT ? | 15:02.03 |
| Robin_Watts | Smart Office Technologies. The company formerly known as Picsel. | 15:02.19 |
| kens | oh right | 15:02.26 |
| Robin_Watts | or the former company formerly known as Picsel. | 15:02.29 |
| | In principle he's interested in the possibilities of licensing us what we need. | 15:02.53 |
| kens | Sounds good | 15:03.13 |
| | sounds better than LO anyway | 15:03.21 |
| Robin_Watts | I'm going to send him an email with more questions etc for him to talk over with his lawyers etc, and we'll see where we land. | 15:03.30 |
| henrys | Robin_Watts: we really don't want a license we want a buyout that we can open source. | 15:03.42 |
| kens | I'm getting weird results from the cluster. Changes in non-pdfwrite code after I changed pdfwrite. | 15:04.01 |
| | I'm doubtful they will do us a buyout after licencing to others | 15:04.26 |
| Robin_Watts | henrys: I said that open sourcing it would be a priority for us. | 15:04.30 |
| kens | OK I'll shut up then.... | 15:04.40 |
| Robin_Watts | he says that he thinks the previous licenses have basically said "do what you want with it" | 15:04.49 |
| henrys | Robin_Watts: oh okay that's great then. | 15:05.15 |
| Robin_Watts | so on that basis, open sourcing it shouldn't be a problem. But that's one of the things he wants to talk over with his lawyer. | 15:05.15 |
| kens | O.O | 15:05.15 |
| | Sounds promising though | 15:05.32 |
| Robin_Watts | yeah. | 15:05.42 |
| chrisl | kens: it depends - if the primary intent was to ensure customers of the ex-company weren't left with an unsupportable product, open sourcing may not be seen as a problem | 15:06.06 |
| Robin_Watts | chrisl: Well, they are administrators, so their primary intent is getting as much money in as possible :) | 15:07.17 |
| | But from the buyers point of view, yes, it's to ensure that they don't get an unsupported product. | 15:07.38 |
| chrisl | Robin_Watts: and if they've already sold licenses to most existing customers, charging us a premium to allow open sourcing could be seen as a last squeeze.... | 15:08.49 |
| henrys | and I assume paulgardiner and Robin_Watts would be somewhat familiar with the code? | 15:10.08 |
| Robin_Watts | chrisl: Yes. But then everyone else was interested in buying more code than we are. | 15:10.16 |
| | They want a complete working system (app, display engine, document agents etc), we just want the agents. | 15:11.08 |
| | henrys: We've had fingers in lots of the code, yes. The bits we haven't had, we know people that have. | 15:11.45 |
| paulgardiner | agents and layout | 15:12.16 |
| Robin_Watts | paulgardiner: yeah. Various bits of the agents are done as libs too, like escher. | 15:12.52 |
| paulgardiner | right | 15:13.11 |
| henrys | chrisl: do you know anything about this bounded huffman stuff I don't see it used in the lib.mak | 15:13.23 |
| chrisl | henrys: I can't find it used anywhere - I'm part way through ripping it out (also the Burrows-Wheeler stuff, too) | 15:14.25 |
| henrys | I was looking at the ccitt code yesterday for a fuzz problem and noticed that. | 15:15.28 |
| | chrisl: I noticed you've worked on ccitt recently. did you notice this -ss->Columns & 7 stuff numbering the bits backward and comparing if the bit is smaller ⦠q_at_stop() ⦠I really can't figure out the rationale for that move, other than to waste a lot of my time figuring it out. | 15:17.33 |
| chrisl | henrys: I didn't - the two things I did in there were very self contained. I can take a closer look if you like (but next week!) | 15:18.39 |
| Robin_Watts | -x & 7 is sometimes used because it's a lot simpler than doing... (8-(x & 7) &7 and then | 15:21.06 |
| | (8-(x & 7)) &7 even | 15:21.20 |
| | I had to do that in the code that aligns a buffer. | 15:22.10 |
| henrys | Robin_Watts: I don't understand why end_bit would not be x & 7 then q_at_stop() would be qbit > end_bit, | 15:22.49 |
| Robin_Watts | I can't comment on this particular case. | 15:23.40 |
| henrys | Robin_Watts: I don't like looking for overflow with qbit <= end_bit - I looked at that and assumed it was a coding error. | 15:23.54 |
| chrisl | henrys: the earliest reference I can find to the bounded huffman code is in the changelog for gs 3.xx, and that's a bug fix. so I can (so far) find no explanation for why it was added. | 15:23.55 |
| henrys | chrisl: well I'm glad it's on your removal listâ¦. | 15:24.46 |
| Robin_Watts | henrys: Want to log into skype for a mo ? | 15:25.12 |
| henrys | yes | 15:25.22 |
| chrisl | henrys: in cases like this I tend to think the best idea is to remove it, and if anyone complains we'll put it back, and fix it...... | 15:25.33 |
| henrys | chrisl: well it would also allow us to collapse some more macros - I guess there are a set of macros shared by the bounded stuff and scfd.c | 15:29.58 |
| chrisl | henrys: could be. I'm just always suspicious of code that hasn't compiled in 5+ years - there is almost no chance it hasn't bitrotted | 15:31.04 |
| henrys | chrisl: go ahead and pull it now I'm doing some stuff with scfd.c and that would help. | 15:31.46 |
| chrisl | henrys: just a clusterpush (for safety) and I'll push the change - I suddenly realised there was a reference in Develop.htm I need to remove | 15:32.52 |
| henrys | chrisl: great | 15:33.10 |
| tor7 | paulgardiner: patch looks good to me. want me to push it? | 15:33.31 |
| chrisl | henrys: there are definitely some hideous macros in shc.h :-( | 15:37.47 |
| henrys | well if we get rid of that file they don't need to be shared and can become inline functions, right? | 15:40.36 |
| chrisl | Probably yes, but I was thinking more of: hcd_declare_state/hcd_load_state()/hcd_store_state() - I hate hiding details like that.... | 15:42.01 |
| henrys | chrisl: we can get rid of those too I was less inclined to do so if they were shared, now they're not. | 15:43.39 |
| | well my old house is under contract already. | 15:45.25 |
| chrisl | henrys: suspect files suitably zapped.... | 15:56.30 |
| henrys | chrisl: thanks | 16:00.07 |
| marcosw2 | cluster sure is busy this morning :-) | 16:26.41 |
| kens | keeps you warm :-) | 16:27.05 |
| Robin_Watts | I'm beginning to think that I shouldn't have had a "num_planes" field, I should have had an "is_planar" field. | 16:27.39 |
| | as num_planes == color_info.num_components whenever is_planar. | 16:28.03 |
| | and some of the recent SEGVs I've solved have been where num_planes and num_components are getting out of sync. | 16:28.39 |
| | I may go through and change the code in a bit. | 16:28.49 |
| henrys | mvrhel_laptop, Robin_Watts: marti has started. | 16:36.31 |
| mvrhel_laptop | oh ok great | 16:36.43 |
| Robin_Watts | ah, fab! | 16:37.18 |
| ray_laptop | morning, all. | 16:51.08 |
| Robin_Watts | Morning ray. | 16:51.23 |
| ray_laptop | for some reason, my IRC client didn't automatically connect | 16:51.26 |
| | I have a call with cust 532 in a few minutes. | 16:51.53 |
| | Robin_Watts: is there an shorter syntax to fetching the diff for a particular hash other than (e.g) git diff 656f26c~1..656f26c ? | 16:54.39 |
| | Robin_Watts: and how do I push a branch from my local to my repo on peeves ? (i.e., which branch should I be on as the current checkout, and what is the command) ? | 16:56.40 |
| | is it as simple as being on "master" and doing: git push @peeves:git/ghostpdl xxxx ? | 16:58.44 |
| | where xxxx is the branch | 16:59.02 |
| | I hesitate because I've honked up my repo on peeves a couple of times and got it all confused | 16:59.38 |
| Robin_Watts | ray_laptop: sorry, phone. | 17:00.41 |
| | ray_laptop: I'm not sure about the diff. | 17:00.55 |
| | I use "git diff HEAD~5..HEAD~4" a lot :) | 17:01.08 |
| | And to push do: git push remote-name local-branch:remote-branch | 17:01.38 |
| ray_laptop | Robin_Watts: will that work if the remote branch doesn't exist ? | 17:02.13 |
| Robin_Watts | ray_laptop: I think so. | 17:03.21 |
| ray_laptop | ok, thanks. I'll let you know in a bit :-) | 17:03.56 |
| | Yep. It worked -- it created the remote branch and even told me: * [new branch] xxxx -> xxxx | 17:07.33 |
| Robin_Watts | That is one of my favourite hammers. | 17:08.04 |
| | If you do: git push foo :bar then that will delete 'bar' on remote 'foo'. | 17:08.29 |
| | oh, balls. | 17:14.16 |
| | I just realised that I haven't updated the memory device gc stuff to realign stuff after a reloc. | 17:14.53 |
| ray_laptop | Robin_Watts: How is it that a memory buffer every is reloc'd ? It's going to be in a single object large chunk isn't it ? | 17:18.39 |
| | IIRC, any object that is > 1/2 the chunk size (default 20K) is put in its own chunk, right ? | 17:19.59 |
| Robin_Watts | ray_laptop: I have never seen one reloc'd. | 17:20.42 |
| ray_laptop | I suppose a pattern-accum memory device might be small enough, but those don't have special alignment used | 17:20.44 |
| Robin_Watts | But code exists to reloc them. | 17:20.51 |
| ray_laptop | Robin_Watts: probably for the pattern-accum mem devices | 17:21.09 |
| | Robin_Watts: so it doesn't just run set_line_ptrs ? | 17:21.46 |
| Robin_Watts | I do fondly remember a staff meeting discussion a few years ago, where we all earnestly agreed that it would be great to stop having things being gc'd when they didn't need to. | 17:21.56 |
| | ray_laptop: It does not. | 17:22.11 |
| ray_laptop | it probably should | 17:22.34 |
| | once it has done the RELOC_PTR on 'base', it can just as easily rebuild them as run through and subtract the reloc offset | 17:23.42 |
| Robin_Watts | The planar support in gs is partly written as if it's intended to support planes with different colorants having different depths. | 17:23.43 |
| | ray_laptop: Unless someone has set foreign_line_ptrs, and then had their own screwy layout for them. | 17:24.13 |
| ray_laptop | Robin_Watts: I am fine with just commenting that as "LATER" or "FIXME" | 17:24.20 |
| Robin_Watts | ray_laptop: yeah, I might do that. | 17:24.34 |
| | BUT the planar support only actually works if all the planes have the same depth. | 17:24.55 |
| | I do wonder if I should do a tidy up of this code so that we just assume all the depths are the same everywhere. | 17:25.22 |
| | rather than giving people the impression that something is possible that isn't. | 17:25.40 |
| ray_laptop | Robin_Watts: I'm OK with that, as well. It's not like it ever worked. And neither of us can think of why it might be wanted (at least not seriously) | 17:26.31 |
| | but then we were surprised by cust 801 wanting CMYB at 300 and K at 600 | 17:27.02 |
| kens | Night all | 17:32.11 |
| ray_laptop | 'nite, kens | 17:32.21 |
| Robin_Watts | ray_laptop: Likewise can you ever thing of a case where for a planar device we'd want num_planes != color_info.num_components ? | 17:42.40 |
| | Tag planes? | 17:43.30 |
| henrys | chrisl: yes this load and store state is terrible - it leads to many unnecessary assignments that would be immediately noticed if the code were expanded. The compiler probably gets rid of that but geez... | 17:48.31 |
| chrisl | henrys: some of that is due to when I made some of the macros into functions - we have to save the state to call the function, then retrieve the state after. I've been meaning to revisit that, and work out a neater way of doing it | 17:50.21 |
| henrys | chrisl: well I'd like to fool with it. I think I inherited the filters | 17:51.12 |
| Robin_Watts | chrisl: Possibly have all the state in a structure. | 17:51.39 |
| | Then the first call to every function is a pointer to the structure. | 17:51.56 |
| chrisl | Robin_Watts: the state is in a structure, which we copy to local variables, then copy back to the structure at strategic points.... horrible :-( | 17:52.11 |
| Robin_Watts | chrisl: yeah, I assumed that was originally done because there was an 'important' compiler that couldn't optimise it otherwise. | 17:52.47 |
| henrys | once I have the macros expanded I can read the code, I'm a stickler about reading it before modifying it ;-) | 17:53.07 |
| chrisl | henrys: that's just crazy talk...... | 17:53.45 |
| henrys | bbiam | 17:54.38 |
| chrisl | Robin_Watts: I suspected it was performance - a lot of older compilers produced inefficient code for accessing entries in structures. | 17:56.06 |
| | These days, me feeling is we should just ditch it, and deal with the state structure directly. | 17:57.02 |
| | s/me/my | 17:57.08 |
| Robin_Watts | I concur. | 17:57.47 |
| | henrys: At least you aren't aiming to understand it before modifying it :) | 17:58.27 |
| chrisl | I think the CCITT fax code was specifically designed to frustrate attempts to understand it....... | 17:59.35 |
| Robin_Watts | In order to understand any one line of the code, you need to understand the line before it. | 18:00.21 |
| ray_laptop | chrisl: henrys: Yeah, I recall old compilers that would always reload structure elements using the pointer rather than keeping it in a register | 18:00.49 |
| | Some of that was before there was a 'volatile' keyword to tell the compiler when it needed to do that because another thread might modify it | 18:01.58 |
| Robin_Watts | ray_laptop: Well, that's the pointer aliasing nature of C for you. You need to either define pointers to the structures as "restrict", or the functions need to be static and the optimiser needs to be smart. | 18:02.01 |
| | volatile won't help in this instance. | 18:02.26 |
| | volatile says that they MUST be reloaded/rewritten every time they are accessed. | 18:02.46 |
| ray_laptop | Robin_Watts: no, we want the compiler to assume that the struct is *not* volatile and optimize it | 18:02.51 |
| Robin_Watts | and the order can't be changed. | 18:02.55 |
| | ray_laptop: And we want the compiler to know that no other pointer can overlap the structure. Hence restrict is what we want. | 18:03.43 |
| ray_laptop | trying a memento build to see if it hits anything | 18:03.44 |
| Robin_Watts | Down to just 1 segv in psdcmyk now. | 18:05.08 |
| ray_laptop | Robin_Watts: is it that the one that has been there for a long time ? tests_private/comparefiles/Bug693365.pdf.psdcmyk.300.1 Seg_Fault | 18:07.54 |
| Robin_Watts | yes. | 18:08.16 |
| | Ah, that's not my fault? Woo Hoo! | 18:08.25 |
| mvrhel_laptop | bbiaw | 18:13.47 |
| ray_laptop | hmm.. found one issue. When I have NumRenderingThreads > 0, the color_usage_array isn't set up in the rendering thread's device_clist_reader struct, so a process_fn gets a NULL pointer :-( | 18:27.26 |
| Robin_Watts | ray_laptop: oops. | 18:30.50 |
| ray_laptop | Looking into it... | 18:31.07 |
| | OK, so I just have to fix it in the setup and teardown, similar to what is done for the icc_table | 19:04.51 |
| | OK. Now band skipping is working with NumRenderingThreads>0 and a release build ! | 19:25.39 |
| Robin_Watts | ray_laptop: Excellent! | 19:25.53 |
| ray_laptop | Now my J12 time with NRT=3 is 15.04 sec | 19:26.19 |
| Robin_Watts | down from? | 19:26.53 |
| ray_laptop | next, I'll see about -dBGPrint=true | 19:26.54 |
| | it _should_ work | 19:27.18 |
| Robin_Watts | I've been distracted by SEGVs, so haven't tried the persistent icc_cache's yet. Will do that on monday. | 19:27.36 |
| ray_laptop | Robin_Watts: that will help more, proportionally on J6x100 right ? | 19:28.10 |
| | there's only 20 pages in J12 | 19:28.28 |
| Robin_Watts | ray_laptop: Yes. | 19:28.38 |
| | but when I profiled it, fully 50% of CPU time was spent in lcms. | 19:28.51 |
| ray_laptop | Robin_Watts: with J6, right ? | 19:29.06 |
| Robin_Watts | No, with J12. | 19:29.14 |
| ray_laptop | oh, wow | 19:29.20 |
| Robin_Watts | (my 100 pages example was purely for ease of elucidation :) ) | 19:29.41 |
| ray_laptop | That doesn't seem right. How many times does it build a new link profile with J12 ? | 19:29.47 |
| Robin_Watts | 4*20. | 19:29.57 |
| | with numrenderingthreads = 4. | 19:30.08 |
| ray_laptop | and that's 50% of the time ??? Wow, we need a new CMS | 19:30.29 |
| Robin_Watts | so naively, we can save 47.5% | 19:30.36 |
| ray_laptop | or we need to get somebody to profile the guts of lcms2 | 19:31.18 |
| Robin_Watts | ray_laptop: When we load a link, it forms an optimised version. | 19:31.53 |
| | performs sampling etc. So the loading of the link is relatively expensive, in order to make the actual usage much faster. | 19:32.25 |
| ray_laptop | mvrhel_laptop: does this seem reasonable to you -- generating 80 link profiles taking 50% of the time. That would be 7+ seconds out of 15 on my laptop | 19:32.26 |
| Robin_Watts | The fact that we throw the link away many times is our fault, not lcms'. | 19:32.54 |
| ray_laptop | my laptop can execute a LOT of instructions in 7 seconds ! | 19:33.03 |
| Robin_Watts | ray_laptop: Please feel free to profile again in case I have misread. | 19:33.13 |
| ray_laptop | Robin_Watts: I might try after BGPrint | 19:33.35 |
| | time for a lunch break | 19:33.51 |
| Robin_Watts | (It's possible I've confused the numbers because of multiple threads being there) | 19:33.54 |
| mvrhel_laptop | ray_laptop: reasonable depends upon the file and the content. | 20:29.55 |
| | the generation of the links is certainly expensive which is why we cache them | 20:30.24 |
| | that is why I did not understand when you wanted to make the cache small for the one customer ray_laptop | 20:30.47 |
| ray_laptop | mvrhel_laptop: I saw you comment in the logs. For cust 532, I did performance testing at various ICC_CACHE_MAX_LINKS level for their performance problem file and found that reducing it killed performance (even 15 was noticeably worse than the default of 50). | 21:51.54 |
| | mvrhel_laptop: I dropped the investigation when they did, but it still seems that that number seems large, given your patch to recognize "same ICC colorspace" that helped the allocation pattern | 21:53.02 |
| | mvrhel_laptop: BTW, did that enhancement ever make it into our tree ? | 21:53.40 |
| | I have to plug in my laptop to validate my numbers, but it looks like -dBGPrint=true gives another 20% or more | 22:13.19 |
| | that's with the cust 801 device | 22:13.37 |
| | that's on J12. On J6 it gets about 15% -- numbers subject to verification | 22:17.33 |
| | but it definitely helps | 22:17.54 |
| | which is *GOOD* | 22:18.01 |
| | _and_ it seems to work without problems (just changing to use gdev_prn_bg_output_page | 22:20.19 |
| | ) | 22:20.28 |
| Robin_Watts | ray_laptop: For the logs; 20% extra is great. I really think the customer should be happy with the results. | 23:36.41 |
| | Forward 1 day (to 2013/11/09)>>> | |
IRC Logs