| | <<<Back 1 day (to 2013/11/04) | 2013/11/05 |
| Robin_Watts | oh, jeez. I should really learn to read clusterpush results :( | 00:50.27 |
| | So just 1 worrying result showing up in the test. Let me try running it in high res... | 00:51.03 |
| tor7 | Robin_Watts: "naughty gcc ways"? | 09:05.59 |
| Robin_Watts | tor7: gcc extensions. | 10:04.16 |
| | like not having to have declarations at the start of blocks. | 10:04.32 |
| tor7 | oh, you mean c99... | 10:04.41 |
| | that 14 year old standard that MS still hasn't bothered to update to | 10:04.58 |
| kens | I'm pretty sure MS doesn't require you to have cdeclarations at the start of blocks, but I think it issues a warning | 10:06.08 |
| | Mayeb I'm wrong, I can't keep the various compilers straight any more | 10:06.25 |
| Robin_Watts | mvrhel hit the problem yesterday, and it was MSVC that whinged, I believe. | 10:11.15 |
| kens | Maybe he has the 'treat warnings as errors' option set | 10:11.37 |
| | BUt anyway.... | 10:11.49 |
| chrisl | IIRC, we disable MS "extensions" for most things except one or two of the third part libs..... | 10:12.29 |
| sebras | http://www.pdflite.com/ I just discovered this project due to wikipedia updating its pdf sw category | 12:28.13 |
| | apparently it is based on sumatrapdf and so it uses mupdf. | 12:28.29 |
| | maybe interesting to see where they take it. | 12:28.52 |
| chrisl | Uses Ghostscript, too...... | 12:34.36 |
| sebras | chrisl: where? how? | 12:35.31 |
| | I can't find it in their source file. | 12:35.38 |
| chrisl | Their "PDF Printer" is just a port monitor, with call out to Ghostscript | 12:35.58 |
| sebras | chrisl: ah, so gs is installed as a separate project? | 12:36.21 |
| chrisl | It looks like it, yes | 12:36.31 |
| kens | and RdMon too presumably | 12:36.46 |
| | RedMon | 12:36.51 |
| sebras | kens: what is redmon? | 12:37.00 |
| kens | port monitor | 12:37.07 |
| sebras | aha. | 12:37.50 |
| kens | Part of the Windows Printing System | 12:38.05 |
| chrisl | sebras: if you look in PsEngine.cpp...... | 12:38.12 |
| kens | captures what goes to a 'port' | 12:38.13 |
| sebras | chrisl: ah, gswin32c.exe. found it. | 12:39.17 |
| kens | So when you print to a PostScripr printer, PS goes to the port. Capture that, feed it to GS and.... | 12:39.18 |
| chrisl | sebras: I don't think sumatra has a "PDF printer", so I wonder why the pdflite source files related to theirs are "Copyright 2012 the SumatraPDF project authors"...... | 12:40.30 |
| sebras | hard to see what is sumatrapdf code and pdflite code. | 12:40.32 |
| | chrisl: well, I do find a PsEngine.cpp even in sumatrapdf... | 12:41.27 |
| chrisl | Oh, I didn't know that. I don't remember pdf creation being listed on Sumatra's website last time I looked | 12:42.19 |
| sebras | chrisl: I'm not sure they _use_ it. | 12:42.37 |
| | chrisl: so... this still puzzles me. can I download pdflite and build from source and get pdflite? | 12:43.34 |
| chrisl | sebras: I don't know, and I'm not really bothered enough to try! It may be that pdflite and sumatra are collaborating, hence the "cross over" of source files | 12:45.03 |
| sebras | chrisl: | you get that vertical bar back, I like periods better than exclamation marks. ;) | 12:46.09 |
| | chrisl: np. I'm just puzzled. | 12:46.37 |
| chrisl | But I was exclaiming my disinclination to try, so appropriate | 12:47.04 |
| sebras | chrisl: no need, I know all of you are usually busy. | 12:47.39 |
| | I'm just a bit sick and at home, so I'm just mucking about. | 12:48.33 |
| chrisl | sebras: I just get a little irritated at applications that proclaim "we support PDF creation" and then buried somewhere else says "if you download Ghostscript to the actual hard bit".... | 12:48.37 |
| | sebras: nothing serious, I hope | 12:48.51 |
| sebras | chrisl: just some stomach-illness I brought with me from shanghai. | 12:49.12 |
| | chrisl: I'm getting better though. :) | 12:49.50 |
| chrisl | "traveller's curse" ;-) | 12:49.58 |
| sebras | chrisl: ! | 12:53.26 |
| tor7 | I would really like to see a "Don't install any Toolbars or other sneak software" clause in the GPL | 13:27.10 |
| | and beware when you update your graphics card drivers, AMD now bundles some crapware that it installs if you don't pay attention | 13:28.18 |
| | (for any windows users) | 13:28.27 |
| Micha` | paulgardiner: Hi! Do I recall correctly that you are in charge of the Android mupdf? | 13:37.15 |
| paulgardiner | Micha`: sorry on the phone. I'll get back to you | 13:39.51 |
| Micha` | No problem. | 13:41.19 |
| paulgardiner | Micha`: I'm back. I wouldn't say I am in charge of the Android build, but I may be able to help on issues with it. | 14:17.57 |
| Robin_Watts | have the clocks changed in the US yet? | 14:19.33 |
| kens | wwI think yes | 14:20.01 |
| tor7 | Robin_Watts: no meeting today though, henrys is moving house? | 14:25.38 |
| Robin_Watts | oh, right, of course. | 14:26.07 |
| | I'd completely forgotten that. | 14:26.19 |
| Micha` | paulgardiner: Well, I have no issue :-) | 14:31.54 |
| paulgardiner | Excellent. That's what I like to hear. :-) | 14:32.15 |
| Micha` | I'm taking mupdf as a base for a PDF annotator I'll need for work. To get use to the library, Android programming, Java programming, and all those hipster things, I did several toy projects. | 14:32.19 |
| | One of them is to integrate a color picker for the Ink annotations, and I'm pretty much done with that. | 14:32.29 |
| | I designed a new paintbrush picker for that in an independent library. So my questions are: 1. Would you be interested in having a look, and possibly integrate the changes? 2. In case of a mid-inking color change, what would be the expected behavior: save the current annotation and start a new one, or change the color of the current one? | 14:32.45 |
| paulgardiner | Nice. | 14:32.48 |
| Micha` | Really, the changes in the software are minim. | 14:33.10 |
| | But boy ho boy did I have a hard time with the color picker. | 14:33.34 |
| paulgardiner | Not sure what's best. One similar app I saw didn't allow setting of colour and width during the addition of the annotation, but allowed for changing those as a separate edit operation. | 14:34.48 |
| Micha` | Whoever documented the Android API should be put under surveillance his schizophrenic behavior. | 14:35.40 |
| paulgardiner | And the choice to edit was provided when the annotation was selected | 14:35.42 |
| Micha` | IIRC, ezpdf allows for the change by saving the current annot and creating a new one. | 14:36.11 |
| paulgardiner | Yeah. It makes sense to have a single color for each annotation because that makes the interface true to the PDF format, although it might not be the most convenient for the user. | 14:38.04 |
| | I think its Adobe Reader that creates ink annotations with whatever color and width was last selected, and then you can touch select them to change any aspect | 14:38.52 |
| Micha` | What I can do, though, is to provide the palette button on the annotation bar (the one with highlight, underline, strike, and ink). That way, the color is fixed beforehand. | 14:39.10 |
| paulgardiner | The downside of that is you probably don't want the same color for each type of annotation. | 14:40.11 |
| | Presumably the palette button would set the color for all the annotation types. | 14:40.34 |
| Micha` | Color customization makes sense for the other ones, though I planned to store the color in different parameters for each. | 14:40.35 |
| | Precisely. | 14:40.43 |
| paulgardiner | The Adobe way is quite nice because whenever you create an annotation you get whatever color you last selected for that annoation type. | 14:41.33 |
| | Also avoids the need for an extra button. | 14:41.44 |
| | ... at least on that menu bar | 14:42.03 |
| | But I'm not particularly against other schemes. | 14:42.44 |
| | Ah hang on. I know another argument for it: to be able to edit the color of an existing annotation is needed any way, so it makes sense to make that the main way to do it. | 14:43.56 |
| Micha` | Editing the color of an already stored annotation would require a little bit more work, but I know how to do it, and that's still formative. However, isn't it a little bit counterintuitive to first draw something then change its color? | 14:46.41 |
| | Maybe we can find a nice design to select the color of an annotation type in the annot bar too... | 14:47.51 |
| paulgardiner | I have no hard oppinion. The only thing I will say, is I was surprised how well the create-then-edit method worked. Seemed quite natural in a touch-based UI where operations are so quick | 14:51.34 |
| tor7 | Robin_Watts: a handful of commits on tor/master for review when you've got a mo | 14:52.36 |
| paulgardiner | ... and come to think of it, it's no greater a number of operations than the other way around - just a smaller UI | 14:53.31 |
| Robin_Watts | tor7: if (*p++ == '>) goto parse_text; ? | 14:54.07 |
| | but that's purely a style thing, that commit is fine. | 14:54.32 |
| | and the dash_len one is fine too. | 14:55.00 |
| tor7 | Robin_Watts: hm, let me ponder the style thing | 14:55.10 |
| | no, it needs to be a while. it's skip until '>' or end of string | 14:55.46 |
| | but I see what you mean | 14:55.56 |
| Robin_Watts | I wasn't suggesting not having as a while. | 14:56.35 |
| | just that the inner bits could be simplified. | 14:56.43 |
| tor7 | yeah, I see what you mean now | 14:56.55 |
| Robin_Watts | The tree one... I am not familiar with AA trees. | 15:00.56 |
| tor7 | Robin_Watts: pull again, I one-linerised it as you suggested. much more comprehensible that way. | 15:00.58 |
| Robin_Watts | what's the benefit to the use of sentinel rather than just 'NULL' ? | 15:01.21 |
| tor7 | https://en.wikipedia.org/wiki/AA_tree a simplified variant of a red-black tree | 15:01.24 |
| sebras | tor7: I'd agree, but all my colleagues would disagree. I'm so happy to be part of mupdf! :) | 15:01.35 |
| tor7 | Robin_Watts: it makes the inner loops easier (no need for special casing NULL tests) | 15:01.50 |
| Robin_Watts | Arne Andersson. Any relation? :) | 15:02.15 |
| sebras | tor7: isn't there a bug in the fz_debug_xml()? in the new for-loop you fz_debug_xml item->down... shouldn't this be child? | 15:02.23 |
| tor7 | sebras: ahem. yes. | 15:02.56 |
| | Robin_Watts: apart from andersson being the #1 most common surname in sweden? nope :) | 15:03.26 |
| sebras | tor7: the aa-tree is supposed to be used for text-search? | 15:04.47 |
| tor7 | sebras: I'm using it to look up nodes by id-name in the svg parser | 15:05.12 |
| Micha` | paulgardiner: Ok, sounds good. I'll get back to you when it's done then! | 15:05.22 |
| tor7 | our hash table is optimised for fixed key lengths | 15:05.22 |
| | and an aa-tree is trivial to implement... | 15:05.36 |
| Robin_Watts | tor7: As a style thing, I prefer to typedef a function type and use that as an arg. | 15:05.36 |
| | rather than having void (*arg)(.......) everywhere. | 15:05.51 |
| paulgardiner | Micha`: excellent | 15:06.06 |
| tor7 | Robin_Watts: we could make a generic fz_free_func typedef, I think we have that same function pointer signature in a couple of other places | 15:06.14 |
| Robin_Watts | I can see a few places where the sentinel stuff avoids checks, yeah. | 15:06.19 |
| | tor7: OK, all lgtm. | 15:08.01 |
| tor7 | Robin_Watts: fab. I'll fix the bug sebras spotted and push then. | 15:08.29 |
| sebras | tor7: not done with aa-tree, but push if you want. | 15:09.03 |
| tor7 | sebras: I can wait :) | 15:09.37 |
| Micha` | paulgardiner: By the way, I pushed a few bug reports which are somewhat related to annotations and the Android app. I think some of them should be cleared before we commit this whole color picker thing. If you have the time, can you have look? I usually provide patch proposals, so it's basically just a matter of reviewing those. | 15:11.22 |
| paulgardiner | Micha`: oh okay. Will do. Thanks for pointing it out | 15:11.54 |
| Micha` | paulgardiner: No trouble, thanks! | 15:12.12 |
| Gigs- | rayjj: there? | 15:21.24 |
| kens | Bit early | 15:21.32 |
| Gigs- | thanks | 15:22.02 |
| kens | if ray_laptop is here then Ray is here usually | 15:22.24 |
| Gigs- | glad you all didn't talk too much so I could read the scrollback... I need to turn logging on | 15:22.35 |
| kens | this channel is logged | 15:22.46 |
| | you can read the logs.... | 15:22.57 |
| sebras | tor7: ok, done. lgmt too. | 15:24.01 |
| tor7 | Robin_Watts: one more on tor/master (the stroke state on the stack changes we discussed last week) | 15:30.57 |
| marcosw | morning | 15:31.40 |
| sebras | tor7: that's only a renaming commit, no..? | 15:31.47 |
| Robin_Watts | marcosw: Aha, hi. | 15:31.50 |
| marcosw | uh oh | 15:31.56 |
| tor7 | sebras: no? | 15:32.07 |
| Robin_Watts | marcosw: 801 says it's uploaded 2 files to "the ftp site". | 15:32.12 |
| sebras | tor7: or did you stick the stork state commit on tor/svg.. yes. | 15:32.13 |
| tor7 | it changes how fz_keep_stroke_state works | 15:32.25 |
| | sebras: you may have pulled before my push completed | 15:32.32 |
| | it's on both tor/svg and tor/master | 15:32.36 |
| sebras | tor7: whoa! indeed. refetching moved tor/master | 15:33.02 |
| marcosw | Robin_Watts: there is a new "data_file.zip" that contains two files. | 15:33.30 |
| mvrhel_laptop | meeting time? | 15:33.43 |
| chrisl | Phew, almost late again..... | 15:33.56 |
| Robin_Watts | tor7: That looks lovely. | 15:33.56 |
| | mvrhel_laptop: No meeting this week, henrys is moving house. | 15:34.08 |
| tor7 | mvrhel_laptop: chrisl: henrys is out today, I believe the meeting is cancelled. | 15:34.09 |
| Robin_Watts | mvrhel_laptop: You can go back to bed for a bit :) | 15:34.17 |
| | marcosw: OK. I'll need to look for the login details again... | 15:34.42 |
| chrisl | tor7: doh, of course! Ah well..... | 15:34.49 |
| marcosw | I'll just put it on casper | 15:35.03 |
| mvrhel_laptop | how did i miss that important memo | 15:35.07 |
| tor7 | chrisl: for once I remember the time correctly, and the meeting is cancelled :) just my luck... | 15:35.14 |
| mvrhel_laptop | oh there it is | 15:35.36 |
| | it was too far in advance | 15:35.56 |
| sebras | tor7: I don't understand the code, but I spot no errors. | 15:36.10 |
| mvrhel_laptop | in that case bbiab | 15:36.35 |
| chrisl | tor7: well, at least I didn't actually rush back - I just couldn't hit another squash ball to save my life, so ended the session | 15:36.56 |
| marcosw | Robin_Watts: okay, ~marcos/data_file.zip is on casper. | 15:37.05 |
| tor7 | sebras: currently we have to create a new fz_new_stroke_state for each graphics call, and make sure to keep it 'const' after use so we don't mess up the display list | 15:37.39 |
| | I wanted a use case where I could keep the stroke state on the stack, and have the display list automatically create its own clones | 15:38.00 |
| | so I don't have to worry about clobbering old data, and not worry about object lifetimes | 15:38.28 |
| | this was the easiest way I found, that didn't mess with existing code | 15:38.44 |
| | sebras: the reason we don't do this always is because we can support arbitrary dash pattern lengths (and thus need to keep stroke states in the heap) | 15:39.35 |
| sebras | tor7: ok. so presumably fz_default_stroek_state will be used elsewhere later on. | 15:39.42 |
| tor7 | sebras: in the svg device :) | 15:39.50 |
| sebras | tor7: ok. | 15:39.57 |
| tor7 | in the "Implement graphcs state stack" commit | 15:40.00 |
| sebras | I like that you separate out commits in logical steps. I'm sooo unused to that when reading patches at work. :-/ | 15:40.55 |
| tor7 | the svg parser can tiger, and read back robin's svgdevice output for paths and text (which he draws as symbol/use paths) | 15:41.12 |
| Robin_Watts | tor7: Oh. that's excellent! | 15:41.31 |
| tor7 | sebras: it's all your fault! | 15:41.44 |
| Robin_Watts | I didn't realise we could eat our own dog food yet. | 15:41.45 |
| sebras | tor7: sorry, but it makes the git look nice. :) | 15:41.56 |
| tor7 | Robin_Watts: we can't do much else, but that's my primary goal :) | 15:41.59 |
| ray_laptop | morning, all | 15:42.58 |
| | good thing there is no meeting. The kids were running late today. | 15:43.12 |
| Robin_Watts | Morning ray_laptop | 15:43.46 |
| ray_laptop | School doesn't start until 7:48, but they like to get there early (usually) to chat with their friends. Today they were dragging | 15:43.53 |
| Robin_Watts | I have 3 commits on robin/master that should get the alignment stuff working. | 15:44.01 |
| kens | ray_laptop : Gigs was looking for you earlier | 15:44.14 |
| sebras | tor7: question though... in fz_clone_stroke_state(), extra seems to refere to the unused entries in dash_list. why do you need to copy them? and wouldn't you copy too little data into the clone? | 15:45.07 |
| ray_laptop | kens: thanks. I see. But he didn't ask a question fo rthe logs. I'll check my email | 15:45.24 |
| kens | He's onlione so I guess he will ask again | 15:45.42 |
| sebras | tor7: to me nelem - len would make sense. | 15:45.50 |
| | tor7: maybe. | 15:45.56 |
| tor7 | sebras: stroke->dash_list is at the end of the struct and always has 32 entries | 15:46.12 |
| | extra is how many extra entries over those 32 that are malloced | 15:46.26 |
| ray_laptop | kens: yes, especially since you mentioned his name (if he has highlighting on) | 15:46.39 |
| tor7 | so yes, we might copy less than the full struct if dash_len < 32 | 15:46.53 |
| sebras | tor7: but then clone->dash_len would be <32 so it ought not to be a problem. | 15:47.33 |
| | tor7: at the same time as I realized that dash_list was 32+ entires I promptly forgot about it... | 15:48.10 |
| | tor7: ok, no more reviews today. | 15:49.51 |
| ray_laptop | marcosw: where is the FTP site that 801 uses ? | 15:50.19 |
| marcosw | in my home office: ftp://marcosw.no-ip.com | 15:50.57 |
| ray_laptop | marcosw: oh, thanks. I was looking on casper :-/ | 15:51.21 |
| marcosw | I put the latest file from customer 801 on casper: ~marcos/data_file.zip | 15:51.49 |
| ray_laptop | marcosw: I don't think I have the password for that. | 15:51.56 |
| marcosw | to make it easer for Robin_Watts. | 15:52.06 |
| ray_laptop | marcosw: I did see data_file.zip on casper. | 15:52.07 |
| | is it still being uploaded ? | 15:52.18 |
| marcosw | ray_laptop: I'll forward the password login information to you. | 15:52.23 |
| | ray_laptop: no, it's ocmplete | 15:52.44 |
| Robin_Watts | marcosw: Thanks! | 15:53.03 |
| ray_laptop | marcosw: I echo "Thanks" | 15:53.17 |
| Robin_Watts | ray_laptop: I've just got the pad/align stuff passing all my tests, so I'm going to modify the 801 device to use it, fix the SSE to use the aligned versions and then do some timing tests. | 15:54.28 |
| ray_laptop | Robin_Watts: were the mods to allow timing (suppress output) in the 801.tar.gz ? | 15:55.10 |
| marcosw | I've emailed tech@artifex with the customer 801 ftp site login information. | 15:55.13 |
| ray_laptop | marcosw: thanks | 15:55.23 |
| | Robin_Watts: I've got a branch with your changes, so if you update the 801.tar.gz, it would be appreciated (or if you also are on a branch, just send me the patch) | 15:56.45 |
| | Robin_Watts: but I think you mentioned that you weren't using git because you didn't want to inadvertently 'push' | 15:57.41 |
| Robin_Watts | ray_laptop: When I get it working, I'll update the zip, yes. | 15:58.43 |
| ray_laptop | Robin_Watts: Ta | 15:59.00 |
| Robin_Watts | ray_laptop: The mods to allow timing may not have been in 801.tar.gz | 15:59.04 |
| | Did someone on here mention an nmake clone that uses multiple cores? | 15:59.25 |
| ray_laptop | Robin_Watts: it didn't look like it | 15:59.30 |
| Robin_Watts | I am trying 'jom', but that doesn't seem to like our makefiles. | 15:59.44 |
| chrisl | ray_laptop, Robin_Watts: it (jom) doesn't work: it doesn't seem to correctly support the "include" directive :-( | 16:00.54 |
| Robin_Watts | chrisl: Right, that was what I thought. Shame. | 16:01.30 |
| chrisl | And as it's "good enough" to build qt, I doubt our weird requirements will be fulfilled unless we hack on it ourselves.... | 16:02.33 |
| Robin_Watts | Hmm. There are fixed bugs in there wrt !include, so it does support that... | 16:03.02 |
| chrisl | Yep, but there is something in *how* supports it that is missing. | 16:04.09 |
| Gigs- | ray_laptop: hey.. heh yeah I know what you meant about the banging it... once you get a bad knuckle it just gets worse | 16:04.20 |
| chrisl | Robin_Watts: or maybe it doesn't like recursive calls? I can't remember what target(s) I tried | 16:04.55 |
| Gigs- | ray_laptop: for my purposes I may be able to ignore DN colorspaces and just mess with separation spaces... a lot of the times these programs seem to put colorants into DN spaces they didn't need to be in | 16:05.01 |
| Robin_Watts | It complained that it couldn't find 'debugclean:' for me. | 16:05.11 |
| chrisl | I tried a couple of targets, it complained about not finding any of them | 16:05.57 |
| Gigs- | ray_laptop: sometime when you have a few minutes I'd like to expand on what you were telling me about the planar rendering | 16:06.50 |
| marcosw | bbiab | 16:07.07 |
| paulgardiner | tor7, Robin_Watts: why does fz_expand_rect not expand empt rectangles? Answering my own question, I suppose in many cases empty rectangles are uninitialised, but I have a case where the rectangle is initentionally a point. | 16:08.26 |
| chrisl | Robin_Watts: TBH, I wasn't inclined to devote much more than a cursory look at jom - I'm not going to substantially rejig the Windows build to get it working with jom, so.... | 16:09.40 |
| Robin_Watts | paulgardiner: An empty rectangle is any rectangle where x1 < x0 or y1 < y0 | 16:09.54 |
| | chrisl: no, indeed. i might play with the jom sources. | 16:10.07 |
| | paulgardiner: So how can you expand an empty rectangle meaningfully? | 16:10.24 |
| chrisl | Robin_Watts: it might be worth seeing what the diagnostics output says | 16:10.46 |
| Robin_Watts | suppose I take the intersection of 2 rectangles (0,0)->(1,1) and (2,2)->(3,3) | 16:10.56 |
| | That's empty. | 16:10.58 |
| | How can I expand that? | 16:11.02 |
| | chrisl: I tried, it didn't say anything. I'll play at some point. | 16:11.23 |
| chrisl | Robin_Watts: ah, less than useful :-( | 16:11.54 |
| tor7 | Robin_Watts: no, an empty rectangle is one with x0==x1 or y1==y0. your case is the infinite rectangle. | 16:13.07 |
| | paulgardiner: am empty rectangle with a defined position, and an empty rectangle with no position, that's a good question how to distinguish | 16:13.30 |
| paulgardiner | Yeah | 16:13.39 |
| | I can do the expansion in line in the place where I know it is intentionally a single point. | 16:14.23 |
| tor7 | paulgardiner: I am afraid that expanding an empty rectangle might potentially break some assumption somewhere | 16:14.39 |
| paulgardiner | But I was just checking we think the current imp is correct | 16:14.47 |
| Robin_Watts | paulgardiner: That would seem the best solution to me, unless you can come up with a better representation of empty/infinite rects. | 16:14.56 |
| tor7 | if you check the use cases, it might turn out that we can safely expand empty rects (the default fz_empty_rect is just located at 0,0) | 16:15.12 |
| paulgardiner | No. I think that's best. I just wanted to check what you thought | 16:15.20 |
| tor7 | but I think we may have some optimisations where we return fz_empty_rect if an intersection is empty, and that is supposed to be at an undefined location | 16:16.28 |
| paulgardiner | I guess we could have fz_expand_known_to_be_welldefined_rect... assuming someone could think of a snappy name for it | 16:16.39 |
| tor7 | and then if we expand it to make sure we cover and strokes, it'll go wrong | 16:16.41 |
| | fz_expand_rect_or_point ? | 16:16.56 |
| paulgardiner | Oh yeah | 16:17.06 |
| | But is it worth adding? | 16:17.45 |
| tor7 | paulgardiner: probably not, if you only use it in one spot | 16:17.56 |
| paulgardiner | That is a good name | 16:17.57 |
| | Okay. Thank. I'll stick with the inline code | 16:18.13 |
| tor7 | paulgardiner: or just make it static local to that file | 16:18.27 |
| Robin_Watts | Have it as a static local function for now. | 16:20.21 |
| | That way we can easily make it global if we need it later, and it keeps the code clear. | 16:20.37 |
| Micha` | FWIW, I went through the other use of fz_expand_rect when I was working on this bug, and saw no other obvious occurrence of a potential one point rectangle. | 16:21.13 |
| | However, there are many places where two rectangles are intersected, and no difference is made between a one point intersection and no intersection at all. | 16:21.42 |
| | At the time, Robin told me this is due to the fact that rectangles are bottom-right open and top-left closed, so it probably makes sense. | 16:22.16 |
| paulgardiner | Micha`: Ah. I have a question | 16:23.12 |
| Micha` | We all do. | 16:23.19 |
| | (Though the answer to most is likely "chocolate chips cookies") | 16:23.42 |
| paulgardiner | Your patch looks to avoid the expansion in the non-empty case. Is that a slip? | 16:23.43 |
| Micha` | Sorry, you mean to avoid the expansion in the empty case? | 16:25.00 |
| paulgardiner | Oh no. I see. I'm misreading it | 16:25.37 |
| Micha` | Ahah, I see what you mean. I pondered on using a "non_empty" variable for it to be more readable :-) | 16:26.55 |
| ray_laptop | Gigs-: sorry. I had a phone call. So, what did you want to talk about (something about planar rendering) ? | 16:27.12 |
| paulgardiner | Nah! It's just me being daft. | 16:27.16 |
| Micha` | I'll take your word for it, then :-) | 16:27.55 |
| paulgardiner | I think empty might be equiv to k == 0 | 16:28.02 |
| Micha` | You are right. I didn't read the code close enough. | 16:30.03 |
| Robin_Watts | ray_laptop: Bugger. I haven't fixed the NumRenderingThreads case yet :( | 16:30.18 |
| paulgardiner | It was correct is all that matters. Nice to have this subtle bug fixed | 16:30.34 |
| Micha` | (Though my personal daftness could interfere with my close reading :-)) | 16:31.17 |
| ray_laptop | Robin_Watts: I guess timing when that doesn't work is a bit premature ;-) | 16:36.52 |
| | Robin_Watts: BTW, I suggest timing with NumRenderingThreads=0 as well (just for reference), and I had suggested collecting the timing from the JEITA tests for the customer | 16:37.51 |
| | Robin_Watts: of course, we might want to use some other "well known" tests like PLRM or PDF Reference, and maybe Altona (but those are killers!) | 16:39.10 |
| | The Altona won't show much difference due to your improvements, so maybe leave those out. | 16:39.45 |
| Robin_Watts | ray_laptop: The altona tests are MASSIVELY faster with the new device than the old. | 16:50.38 |
| | but that's more to do with changes from 9.06 to 9.10 | 16:50.49 |
| ray_laptop | Robin_Watts: well, I guess we should mention that to make sure they have sufficient incentive to move to newer versions :-) | 16:56.47 |
| Robin_Watts | My previous mail to them alluded to that, I think. | 16:59.29 |
| paulgardiner | Robin_Watts: little commit on paul/master when you have a moment | 17:01.33 |
| Gigs- | ray_laptop: sorry i had a phone call too :P | 17:04.18 |
| Robin_Watts | paulgardiner: lgtm. | 17:04.43 |
| Gigs- | ray_laptop: planar means it's maintaining for example an 8 bit raster plane for each colorant right... after all of them are rendered how does it know what overprints what? | 17:05.02 |
| paulgardiner | Robin_Watts: ta muchly | 17:05.43 |
| Robin_Watts | Gigs-: The overprinting is done when we draw into the planes. | 17:06.47 |
| | if we have planes for C, M, Y, K and say, Orange, and Orange is supposed to overprint the others, then when we draw a shape in Orange, that clears that C, M,Y, K planes, AIUI. | 17:07.48 |
| Gigs- | what if you encounter CMY data later that is under the Orange? | 17:09.07 |
| | do you have to pre-sort the rendering process? | 17:09.18 |
| | or is it assumed that overprint is controlled in PDF by the ordering of the objects anyway | 17:09.51 |
| Robin_Watts | Gigs-: I'm no expert here, but I assume that if you meet CMYK later that plots under the Orange, it'll be laid down. | 17:20.30 |
| | mvrhel_laptop is the overprinting expert. | 17:20.38 |
| mvrhel_laptop | what is the question? | 17:21.35 |
| | Gigs. When we are doing a new drawing that is overprint, it uses the overprint compositor to get what was previously drawn and does the proper drawing in the bands that need it | 17:22.38 |
| | i.e. a get_bits of what is in the planes now. | 17:22.55 |
| | then it looks at what colorants are supposed to change and changes only those | 17:23.13 |
| | and then puts the new values back | 17:23.24 |
| Robin_Watts | realises there is stuff about this he hadn't appreciated. | 17:23.55 |
| mvrhel_laptop | this is only guaranteed to work when we maintain a separate plane for each colorant | 17:24.04 |
| Robin_Watts | mvrhel_laptop: if you'll excuse a couple of silly questions... | 17:24.08 |
| | so, overprint is specified in that something says "Orange overprints CMYK" | 17:24.24 |
| mvrhel_laptop | no you don't get to say it overprints only CMYK | 17:24.40 |
| | you could have other colorants | 17:24.52 |
| Robin_Watts | You only get to say "Orange overprints" ? | 17:24.53 |
| mvrhel_laptop | you have two binary settings overprint on/off and overprint mode | 17:25.34 |
| | overprint mode uses special handling for cases where the target value is 0 | 17:25.50 |
| | i.e. no ink yet | 17:25.55 |
| Robin_Watts | Ah, so it's not even a per colorant thing? | 17:25.59 |
| mvrhel_laptop | right | 17:26.07 |
| Robin_Watts | It's just globally 'overprinting or not'. | 17:26.09 |
| | Right. | 17:26.11 |
| mvrhel_laptop | right | 17:26.14 |
| | actually not the target value is 0 | 17:26.36 |
| | but the source color value of 0 has special meaning when mode is set | 17:26.52 |
| Robin_Watts | OK. so suppose I draw something on the page, then I change to Orange, and set overprint mode on. Then I draw that on top. That will remove the CMYK from the parts of the page where the orange goes. | 17:27.00 |
| | Now if I turn overprint off again, and draw on top again, I can get a mix of orange and other colors ? | 17:27.44 |
| chrisl | overprint "on" means don't erase other plates | 17:29.06 |
| ray_laptop | mvrhel_laptop: right, so if you paint with CMYKB = 0xff0000ff00 with overprint mode set to look at colorants, only M and K get modified | 17:29.11 |
| mvrhel_laptop | actually the overprint mode only is relevant for CMYK | 17:29.22 |
| ray_laptop | mvrhel_laptop: so, in my example, B would get modified ? | 17:30.02 |
| mvrhel_laptop | good question | 17:30.11 |
| | acutally no you are correct ray_laptop | 17:30.28 |
| ray_laptop | mvrhel_laptop: OK, thanks. | 17:30.36 |
| mvrhel_laptop | the spec is a little oddly written wrt this though | 17:30.42 |
| ray_laptop | agrees | 17:30.52 |
| mvrhel_laptop | although the spec does say | 17:31.12 |
| | Nonzero overprint mode applies only to painting operations that use the current color in the graphics state when the current color space is DeviceCMYK | 17:31.14 |
| | so this is not a DeviceN color space | 17:31.28 |
| | if you were painting with CMYKB mode should have no effect | 17:31.44 |
| ray_laptop | mvrhel_laptop: right, but our device profile may have B set, right ? | 17:31.51 |
| mvrhel_laptop | oh lets not pull color management into this dicussion | 17:32.16 |
| ray_laptop | mvrhel_laptop: OK. | 17:32.22 |
| | it can be the elephant in the room ;-) | 17:32.43 |
| mvrhel_laptop | so Robin_Watts with overprint on, if you are drawing with Orange only the orange plane will be changed | 17:32.48 |
| | with overprint off, you will end up blowing away the CMYK planes | 17:33.00 |
| | if you are drawing with CMYK values with overprint on and mode on, then which planes get left alone depends upon what source CMYK values are zeror | 17:33.51 |
| | those that are zero will not be drawn | 17:34.00 |
| ray_laptop | mvrhel_laptop: so, just to make sure I understand, with overprint on, and DeviceCMYK source color, it will never modify the Orange plane, right ? | 17:34.23 |
| mvrhel_laptop | right | 17:34.38 |
| ray_laptop | irrespective of overprint mode | 17:34.48 |
| Robin_Watts | mvrhel_laptop: Thanks. | 17:34.49 |
| mvrhel_laptop | oh no | 17:34.55 |
| | oh yes sorry ray_laptop | 17:35.02 |
| ray_laptop | mvrhel_laptop: thanks | 17:35.09 |
| mvrhel_laptop | I was thinking you said irrespective of overprint on/off not mode | 17:35.20 |
| ray_laptop | mvrhel_laptop: np | 17:35.33 |
| mvrhel_laptop | by regardless of the mode, if op is on, the orange plane will be left alone with drawing CMYK | 17:35.47 |
| ray_laptop | mvrhel_laptop: that's what I tried to say :-) | 17:36.13 |
| mvrhel_laptop | right. | 17:36.18 |
| | Now I worry about if we are doing op mode correctly in the DeviceN case where we have CMYK+O . | 17:36.48 |
| | I will have to double check this at some point | 17:37.01 |
| chrisl | mvrhel_laptop: there's also the complication of separation spaces with process color names - so /Separation /Cyan behaves differently to CMYK with MYK all zero. | 17:37.26 |
| mvrhel_laptop | actually a sep space with just C will behave like CMYK with op mode on and M=Y=K=0 | 17:38.05 |
| | that I know works | 17:38.17 |
| chrisl | Yeh, I meant just overprint, not opm | 17:38.30 |
| mvrhel_laptop | right with opm false those will behave differently | 17:38.43 |
| | with opm true they will behave the same | 17:38.50 |
| chrisl | overprint is a messy hack :-( | 17:39.02 |
| mvrhel_laptop | yes. I agree. | 17:39.19 |
| chrisl | Sorry, just sticking my nose in as I don't want to start debugging my next ufst problem :-( | 17:39.43 |
| ray_laptop | Robin_Watts: can a process_fn figure out if it's "dev_" parameter is a clist or not ? | 17:41.41 |
| Robin_Watts | ray_laptop: That's the kind of question I'd ask you :) | 17:42.07 |
| ray_laptop | Robin_Watts: I'm thinking that it will know it is a gx_device_printer, so it should be able to use PRINTER_IS_CLIST, right ? | 17:42.14 |
| Robin_Watts | That's a horrible hack, right? | 17:42.32 |
| | Nothing guarantees that process_page is only called for gx_device_printers. | 17:43.11 |
| ray_laptop | Robin_Watts: well, it's a defined macro, widely used. As long as everybody that wants to know uses the macro, we can always fix it by making it explicit | 17:43.31 |
| | Robin_Watts: a device defines its process_fn, and *it* knows it is a gx_device_printer, right ? | 17:44.09 |
| Robin_Watts | Ok. That is true. | 17:44.27 |
| ray_laptop | Robin_Watts: (I am thinking of the xxxx-aps device, of course) | 17:44.28 |
| Robin_Watts | why should the xxxx-aps device need to know if it's a clist or not ? | 17:44.46 |
| ray_laptop | Robin_Watts: an enhancement I'm working on :-) | 17:45.04 |
| | but to let the secret out, I've fixed cmd_drawing_color_usage for devn colors, and so if a plane has no usage, it will be all 0's | 17:46.28 |
| | so, for that colorant of a band, we can take a really fast path | 17:46.58 |
| | Robin_Watts: and that will be *very* common on things like text pages | 17:47.21 |
| Robin_Watts | ray_laptop: Right. Nice. | 17:48.34 |
| ray_laptop | Robin_Watts: I was also thinking of skipping alll of the average and BNM and packing and just writing 0's if all the input bytes are 0's | 17:48.40 |
| Robin_Watts | yes indeed. | 17:48.50 |
| ray_laptop | Robin_Watts: the latter would take care of margins | 17:49.01 |
| | or places where there is something small on the plane | 17:49.19 |
| | I don't know how much the latter help, since it means a conditional branch, but we can test it | 17:50.24 |
| Robin_Watts | ray_laptop: You're talking about changing the SSE code to spot the all 0 case, right? | 17:50.26 |
| ray_laptop | Robin_Watts: for the second case, yes. The first case doesn't need the SSE loop | 17:50.59 |
| | the second case doesn't help the memory bandwidth, but it does skip quite a few SSE instructions | 17:52.19 |
| Robin_Watts | Yeah, the color_usage let's us just go to a memset. The spotting all 0's does indeed save a lot, and would probably be a smart move. | 17:53.22 |
| ray_laptop | so my guess is that it would help, but for cases where there most of the area is scribbled on (such as the black plane on a text page), we'd have to rely on branch prediction working right | 17:54.30 |
| | there is a way to "hint" a branch prediction, and we could set the hint to "branch not taken" so the case where we have a lot of work to do doesn't get dinged | 17:55.26 |
| | of course, the support for hints is processor dependent, but seems to be a no-op if it is not supported (such as on AMD) | 17:56.09 |
| | but current literature seems to suggest that manual hinting isn't really needed | 17:56.50 |
| Robin_Watts | I can't see that the cost of a test and a branch should be significant. | 18:00.15 |
| | So our big potential MuPDF customer (395) is back in touch again with a list of questions. | 18:00.57 |
| | So I will have to devote some time to that tomorrow to take some timings. | 18:01.17 |
| ray_laptop | Robin_Watts: I can do the timings for cust 801 if you want (once I get your latest code with the alignment and timing mode changes) | 18:04.38 |
| Robin_Watts | ray_laptop: Thanks. | 18:05.10 |
| ray_laptop | Robin_Watts: There is a what looks like a really *ugly* hack in gx_default_create_buf_device -- it uses the "color_usage" to signal "page_device" to the make_mem_device. It used to be based on 'band_complexity" back when we had that :-( | 18:30.26 |
| Robin_Watts | The "special hack for setting up printer devices" ? | 18:32.11 |
| | Yes, I've been working in that area, and while this work has removed one nasty hack, and cleaned up some code, it's left that one. | 18:32.57 |
| | ray_laptop: My first quick test indicates that the aligned SSE is now working. | 18:33.15 |
| ray_laptop | Robin_Watts: great! | 18:33.29 |
| Robin_Watts | I've updated the 801.tar.gz | 18:33.32 |
| ray_laptop | Robin_Watts: thanks. Does it have the timing method changes, too ? | 18:33.55 |
| Robin_Watts | But it relies on the commits on robin/master being applied obviously. | 18:33.56 |
| | ray_laptop: It does. | 18:34.02 |
| | So, can you look over the commits on robin/master when you get a chance please? | 18:34.24 |
| | I'd like your opinion on whether anything there can be done better before we continue. | 18:34.46 |
| ray_laptop | Robin_Watts: OK. I'll look at those, now | 18:34.47 |
| Robin_Watts | Thanks. | 18:34.51 |
| | Hi henrys. Move done ? | 18:39.18 |
| ray_laptop | Robin_Watts: Looks, OK, but you could move the #ifdef TEST_PAD_AND_ALIGN into gxbitmap.h and make it active for all devices (just #define bitmap_raster_pad_align_ to ignore 'pad' and 'log2_alig' and use the test values) | 18:45.29 |
| | that might stress some devices :-) | 18:46.00 |
| Robin_Watts | ray_laptop: No, I definitely don't want to do that. | 18:46.58 |
| | the bugs I have been chasing all day are to do with devices not copying pad and log2_align_mod each time they make a new device. | 18:47.21 |
| | hence having those values ignored would not test the propagation of those values through the system. | 18:47.46 |
| | I picked ppm and psd as being good test candidates cos that's one planar and one not. | 18:48.04 |
| ray_laptop | Robin_Watts: OK. So, the changes look fine. Go ahead with them, as far as I am concerned | 18:48.24 |
| Robin_Watts | ray_laptop: Thanks. | 18:49.33 |
| | ray_laptop: Hmm. | 19:10.58 |
| | On their 2 supplied files (J12 and J6), the old device beats us on J12 (20.3s old vs 20.8s new). | 19:11.41 |
| | but on J6 the new one is a convincing win (30.9 old, 24.5 new) | 19:12.16 |
| henrys | Robin_Watts: yes, I'm in, of course it is all chaos, but most of our stuff is at the new place. | 19:14.51 |
| Robin_Watts | cool. | 19:15.11 |
| ray_laptop | Robin_Watts: so, maybe with skipping some empty planes, we can beat them on J12 as well :-) | 19:15.24 |
| Robin_Watts | ray_laptop: We can hope. | 19:15.33 |
| ray_laptop | Robin_Watts: at least since those are .ps files, they don't have any transparency that isn't flattened | 19:18.37 |
| | Robin_Watts: On J12, many of those pages will be helped with the the SSE skipping 0's on a plane, so I'll definitely tackle that. Some of the pages look like they may be able to skip planes for many of the bands | 19:21.56 |
| | Robin_Watts: like the ones with black text to the left or right of the image will be helped by 0 skipping | 19:22.30 |
| Robin_Watts | ray_laptop: I've just added skipping to the non averaging case. | 19:23.03 |
| ray_laptop | Robin_Watts: Oh, OK. | 19:23.27 |
| | but your timing doesn't include that yet, does it ? | 19:23.54 |
| | 240 ppm on the J6 is pretty impressive (up from 193) | 19:25.49 |
| Robin_Watts | no, not yet. | 19:31.07 |
| | ray_laptop: Hmm. Testing for all the bits of an SSE reg being zero is not trivial :( | 19:36.49 |
| | mvrhel_laptop, ray_laptop: Do either of you guys know any SSE tricks for quickly testing that all the bits in an SSE register are 0 ? | 19:37.32 |
| | I have an SSE register full of zeros if that helps. | 19:37.48 |
| | Hmm. With SSE4 we can do it, but not easily without that. | 19:47.30 |
| Gigs- | Your password format is invalid. Your Passwords must be at least 6 characters long and not start or end with a digit. | 19:55.10 |
| | FUCKING RAGE | 19:55.15 |
| | I'm about to smash this fucking computer, people don't fucking deserve computers | 19:55.31 |
| | I'm going to write a virus that deletes every web site that defines more than 20% of the parameters in px or has a retarded password policy | 19:56.13 |
| | oh hah I'm sorry wrong channel! | 19:56.31 |
| | /rant | 19:56.39 |
| Robin_Watts | Gigs-: I feel your pain :) | 19:57.08 |
| Gigs- | heh, sorry I usually reserve such rants for other channel | 19:57.21 |
| | I hope no one writes that virus now that I'm publicly logged saying that heh | 20:00.26 |
| ray_laptop | Robin_Watts: iirc, there is a 'find first one' kind of thing | 20:01.45 |
| Robin_Watts | ray_laptop: a CLZ operation... | 20:05.05 |
| | I can't find it :( | 20:06.58 |
| ray_laptop | Robin_Watts: but if you have a register that is 0's you can pcmpeqd - Compares 4 32bit integers. | 20:16.58 |
| | as an intrinsic, that is: _mm_cmpeq_epi32 | 20:18.30 |
| Robin_Watts | ray_laptop: And that puts the answer in an mm register. | 20:18.44 |
| | It doesn't let me: if (_mm_cmpeq_epi32(...)) goto skip; | 20:19.03 |
| | Oh, joy. | 20:25.19 |
| | My CPU doesn't support SSE4, hence my carefully written code fails :( | 20:25.39 |
| ray_laptop | Robin_Watts: what did you do that used SSE4 -- I'd only seen SSE3 in the previous ? | 20:27.54 |
| Robin_Watts | ray: _mm_testc128 | 20:28.28 |
| | ray: _mm_testc_si128 | 20:28.42 |
| ray_laptop | Robin_Watts: strange, but the SSE (2,3, 4) that I'm using doesn't mention that :-/ | 20:29.35 |
| Robin_Watts | It's equivalent to the ptest instruction. | 20:32.00 |
| ray_laptop | Robin_Watts: thainks. I found them at: http://software.intel.com/sites/products/documentation/studio/composer/en-us/2011Update/compiler_c/intref_cls/common/intref_sse41_test.htm | 20:33.42 |
| | testz checks for all 0' testc checks for all ones and testnzc checks for at least one 0 and at least one 1. | 20:34.50 |
| | But, I see that these are SSE4 as you mention :-( | 20:35.34 |
| Robin_Watts | not quite. | 20:35.59 |
| | one is (a & b) == 0 | 20:36.15 |
| | one is (a & b) == b | 20:37.01 |
| | and one is wackier :) | 20:37.10 |
| ray_laptop | yeah, the intel guide for testznc says: ( ( (s1 & s2) != 0 && (~s1 & s2) != 0 ) ? 1 : 0 ) | 20:38.27 |
| | which we don't need unless we are going to treat all 1's as an optimized case as well | 20:39.45 |
| Robin_Watts | so I can't see anyway to do this "empty" check without SSE4 that will be any faster than just loading the values into normal x86 registers and checking there. | 20:40.02 |
| ray_laptop | Robin_Watts: well loading something into SSE registers that has already been loaded will at least still be in L1 cache, so will load fast | 20:42.14 |
| | and you can have the SSE4 instruction with conditional compile | 20:42.59 |
| | I have to run a couple of errands. bbiaw | 20:43.25 |
| Robin_Watts | yeah. | 20:43.28 |
| | The zero test costs more that it saves doing it without SSE. | 20:54.37 |
| | The zero test costs more that it saves doing it without SSE. | 21:05.40 |
| | mvrhel_laptop: You here? | 21:08.12 |
| | I've got scott asking me what version of XPS we are shipping. | 21:08.23 |
| henrys | my internet is now about 2x faster than the wireless I have. | 21:27.51 |
| Gigs- | Robin_Watts: in mu when you have your pdf_obj how do you know which type converter to use? | 21:49.47 |
| | like if I'm going over an array pulling elements, how can I detect the type without trying every type conversion to see which one works | 21:50.45 |
| ray_laptop | Robin_Watts: I saw your comment that testing takes longer than the unconditional execution. | 22:33.01 |
| | Forward 1 day (to 2013/11/06)>>> | |
IRC Logs