| | <<<Back 1 day (to 2012/02/08) | 2012/02/09 |
| alexcher | marcosw_: I'll quickly commit a fix that doesn't cache glyphs that are too big. A better fix can be done later. | 00:17.09 |
| sebras | tor8: I didn't see any response concerning the bugs I reported in MuPDF/android. Should I report them in bugzilla for us to keep track of? | 10:41.51 |
| tor8 | yes, please | 10:46.25 |
| sebras | tor8: so paul will not be around to fix those? | 10:51.30 |
| tor8 | you'll have to ask Robin_Watts about that, I think he should be but I haven't seen him in here for a couple of days | 10:52.35 |
| sebras | tor8: right. so I'll file proper bugs for them just so we don't forget. | 10:53.20 |
| Robin_Watts | I'm here. | 10:58.02 |
| | Oh, you haven't seen Paul for a couple of days. | 10:58.19 |
| | We should make a list of all the problems with the android app and send paul a list of them all at once. | 10:59.23 |
| | tor8: Does the ios project build now? | 11:03.49 |
| | Supposedly you made fz_clear_pixmap_with_value take a context? | 11:04.14 |
| tor8 | haven't tried in a few days, I might've forgotten something like that | 11:04.48 |
| Robin_Watts | I hadn't appreciated that. | 11:04.54 |
| | You've made every function take a context whether it needs it or not? | 11:05.06 |
| tor8 | in the name of not having to look up for every function whether it takes a context or not, yes | 11:05.24 |
| | do you disagree with that choice? | 11:08.30 |
| Robin_Watts | I would only have passed contexts to functions that needed them. | 11:09.26 |
| | I thought you were consistently ensuring that pdf_ functions took pdf_documents rather than fz_contexts. | 11:09.57 |
| tor8 | that has one problem though, API stability ... if we change a function implementation, we may need to add (or remove) the context argument | 11:10.41 |
| Robin_Watts | tor8: true. | 11:10.50 |
| tor8 | we discussed the pdf_document / fz_context issue the other day, and settled on keeping the fitz-level resources taking fz_context arguments | 11:11.18 |
| Robin_Watts | but it's hard to see how functions that never allocate/deallocate (like say fz_clear_pixmap) will ever need a context. | 11:11.29 |
| | Yes, I'd conflated the two issues in my head, incorrectly. | 11:11.49 |
| tor8 | yes. there are a few where it seems rather pointless, I agree. | 11:11.52 |
| Robin_Watts | I think the fitz level resources taking fz_context is correct. | 11:12.04 |
| tor8 | keeping a list of exceptions in my head about which functions take a context and which don't ... well, you get my point | 11:12.46 |
| Robin_Watts | I do. | 11:12.55 |
| | Maybe it's the correct thing to do. | 11:13.02 |
| | I mean, if we ever do an opengl thing later, and we use opengl to clear pixmaps, then we may need the context there. | 11:13.25 |
| tor8 | I did go down this road back when fitz started in 2003 or 2004 and used a context everywhere | 11:13.39 |
| Robin_Watts | So maybe I should just shut up. | 11:13.54 |
| tor8 | and came to the same conclusion, pass it everywhere just to play it safe :) | 11:13.57 |
| | it is more typing, and it is one more argument to keep passing along, and it is annoying, yes :) | 11:14.20 |
| | but arguably less annoying than looking up every function in the header wondering, did this one take a context or not, I can never remember | 11:14.56 |
| | Robin_Watts: okay, iOS build fixed | 11:16.16 |
| kens | Robin_Watts: | 12:10.34 |
| | http://www.reghardware.com/2012/02/09/valve_portal_gun_to_shoot_onto_shelves_soon/ | 12:10.34 |
| Robin_Watts | kens: hehe | 12:49.23 |
| | tor8: New branch in my repo on casper; pg_android | 15:08.48 |
| | tor8: Do you have an example cbz to hand ? | 15:36.05 |
| tor8 | Robin_Watts: just zip up a couple of jpeg or png images and rename to cbz | 15:36.32 |
| Robin_Watts | Named how ? | 15:37.39 |
| | (ie. how does it determine page ordering?) | 15:37.54 |
| tor8 | alphabetic sort | 15:37.59 |
| Robin_Watts | Just updating android app to use the document interface. | 15:38.28 |
| | Lovely. | 15:39.11 |
| henrys | tor8:I'm really liking raph's inconsolata font. | 15:40.25 |
| kens | chrisl did you see GG's full year results? they broke even! | 16:22.43 |
| chrisl | kens: no, I didn't realise they were due out - cor, broke even, eh? That's almost good! | 16:23.31 |
| kens | :-) | 16:24.10 |
| chrisl | I wonder if the fourth quarter profits were a real improvement, or a side effect of the currency fluctuations.... | 16:25.28 |
| henrys | we better go hire their best people again. | 16:36.58 |
| kens | :-) | 16:37.20 |
| ray_laptop | how can these guys stay in business. I tried installing the VS profiler patch(es) that mvrhel posted here the other day -- They all claim that I don't have VS installed and then the installers bomb with "the program has stopped working" | 17:03.23 |
| mvrhel | hmm. worked fine for me | 17:03.47 |
| ray_laptop | obviously they need ten times as many software engineeers as they have ;-) | 17:03.57 |
| mvrhel | hehe | 17:04.03 |
| ray_laptop | mvrhel: well, thanks. I'm running Win 7 Pro 64-bit -- what are you on ? | 17:04.18 |
| mvrhel | Win 7 Home Premium 64 bit | 17:04.43 |
| | what ever that means... | 17:05.00 |
| ray_laptop | oh, well. I give up | 17:05.03 |
| mvrhel | do you have SP1 for VS? | 17:05.13 |
| | ray_laptop : go to the about Microsoft Visual Studio in the help menu | 17:06.29 |
| ray_laptop | mvrhel: maybe that's it -- it says 9.0.21022.8 RTM (the .NET Framework is Version 3.5 SP1) | 17:08.01 |
| mvrhel | mine is Version 9.0.30729.1 SP and net version 3.5 SP1 | 17:09.06 |
| ray_laptop | when I click 'Check for Updates' it just tells me to start Windows Update from the start menu | 17:09.09 |
| | but I run automatic updates, so it doesn't show anything. I guess I have to go looking for SP1 | 17:10.11 |
| mvrhel | yeah. I think they have all the ms product updates tied in with the other updates | 17:10.14 |
| | yes | 17:10.16 |
| kens | Time for me to go, night all | 17:10.20 |
| mvrhel | I had to do that | 17:10.24 |
| ray_laptop | 536 Mb :-( | 17:11.15 |
| mvrhel | ouch | 17:11.24 |
| ray_laptop | oops -- 536 Kb I miread it | 17:11.46 |
| | s/miread/misread/ | 17:11.57 |
| mvrhel | ah much better | 17:12.07 |
| ray_laptop | not really -- that's just the download and install applet :-( | 17:14.15 |
| | the download status estimates 58 minutes to completion :-( | 17:14.45 |
| chrisl | I've got a VS2005 service pack ISO image which comes to 4.3Gb somewhere! | 17:16.05 |
| ray_laptop | when I ran the applet it just went away, so I tried it again -- after about 45 seconds the first one started, then a few seconds later I had two of the applets running :-/ | 17:16.18 |
| chrisl | Robin_Watts: got a minute? | 17:17.08 |
| ray_laptop | chrisl: I'm only bothering with VS 2008 for now -- I don't have the version of 2005 with the profiler | 17:17.12 |
| Robin_Watts | chrisl: Sure. | 17:18.23 |
| chrisl | ray_laptop: I doubt you'd want a 4.3Gb service pack, anyway! They released smaller ones a bit later, with only one language in each (the DVD ISO has all the language options in one image) | 17:18.27 |
| | Robin_Watts: I stumbled across a comment you added in gsptype1.c | 17:18.56 |
| | Line ~253 | 17:19.18 |
| ray_laptop | oh oh -- chrisl must be working on cust 532's problem | 17:19.21 |
| chrisl | ray_laptop: yep..... | 17:19.32 |
| ray_laptop | chrisl: thanks for the help on that | 17:19.45 |
| chrisl | Robin_Watts: the route of cust 532's issue is the way we're futzing with the step matrix in there, and for the life of me, I can't figure out *why* we're doing it. I know you didn't do the code, but I know you played with that area, so...... | 17:20.50 |
| | s/route/root | 17:20.57 |
| | ray_laptop: np, I figured you had your hands full (which might be why Len punted it my way) | 17:21.33 |
| ray_laptop | chrisl: no, I asked him about that yesterday -- he just sort of saw "Type 1" and thought fonts | 17:22.28 |
| Robin_Watts | chrisl: Looking now. | 17:22.30 |
| | chrisl: Is this in current code, or in their code? | 17:23.01 |
| chrisl | Robin_Watts: current code - the active code in the same, but your stuff is only in current | 17:23.31 |
| ray_laptop | their code is MUCH different to what Robin_Watts did for the mainstream | 17:23.43 |
| | Robin_Watts cleaned up much of the hackery I put in when I did it for cust 532 | 17:24.28 |
| chrisl | ray_laptop: for pattern tiling? | 17:24.34 |
| ray_laptop | well, mvrhel and I | 17:24.43 |
| | chrisl: pattern clist mods | 17:25.02 |
| Robin_Watts | This isn't pattern clist (necessarily). | 17:25.24 |
| | As I understand it, people expect to be able to do a pattern where they draw thin lines around a pattern cell and see that mark 'inside' the pattern cell at all edges. | 17:26.21 |
| chrisl | Robin_Watts: yes, but after that, we round the entries in the matrix to integers - and that seems to be the problem | 17:28.02 |
| Robin_Watts | Where's that ? | 17:28.23 |
| chrisl | Line 282 (for example): inst.step_matrix.xx = (float)floor(inst.step_matrix.xx + 0.5); | 17:29.26 |
| | (in the current code) | 17:30.10 |
| Robin_Watts | Right. My code does the scale using that recalculated value. | 17:30.25 |
| | whereas the old code truncates the value, and then might not alter the scaling of the matrix. | 17:30.53 |
| | or something. My goldfish memory is coming into play here. | 17:31.30 |
| | Does the current code on the trunk show the same problem as they are seeing ? | 17:32.02 |
| chrisl | Yes, exactly the same problem.... | 17:32.15 |
| Robin_Watts | OK. Does enabling my code (both the X and Y blocks) solve it? | 17:32.29 |
| chrisl | No :-( | 17:32.42 |
| Robin_Watts | Bugger. | 17:32.46 |
| chrisl | But, if I disable *all* the experimentation macros, we match Acrobat virtually pixel for pixel, wheras as it stands, our tiling quickly goes out of alignment - so it might be the line compensation | 17:32.48 |
| Robin_Watts | The only one currently enabled is ADJUST_AS_ADOBE | 17:33.37 |
| chrisl | Yes, which doesn't match Acrobat at all | 17:34.03 |
| Robin_Watts | So the current code with ADJUST_AS_ADOBE only kicks in, if the integer bbox for the pattern is within 1/2 a pixel of the step size. | 17:35.08 |
| | and then only if the step size is more than 2 pixels | 17:35.45 |
| chrisl | I'm wondering if this is a low resolution "fix" which doesn't apply at, in this case, 600dpi....... although, I get visible problems at lower res, too | 17:36.45 |
| Robin_Watts | To quote from the spec: | 17:37.24 |
| | TilingType 1: Constant Spacing; Pattern cells are spaced consistently - that is by a multiple of a device pixel. To achive this, the viewer application may need to distort the pattenrcell slightly by making small adjustments to XStep. YStep and the transformation matrix. The amount of distortion does not exceed 1 device pixel. | 17:38.26 |
| | That sounds like a pretty exact definition of what we are doing here :) | 17:38.40 |
| chrisl | Hmm, and in the PS world, it almost certainly wouldn't be a problem, but the way PDF anchors patterns means such small adjustments can become significant | 17:39.39 |
| Robin_Watts | Anchors patterns ? | 17:40.02 |
| | (That's from the PDF spec) | 17:40.21 |
| | What visual effect are you seeing? White lines? | 17:40.38 |
| chrisl | PDF patterns are rendered as if the pattern starts at the page origin, whilst PS patterns start at the current origin | 17:41.01 |
| | Or YStep is slightly larger than Acrobat's, so the visible pattern cells don't match up. | 17:42.07 |
| | If you want a test file, look at fts_06_0618.pdf @600dpi and look at the bottom and top of the hourglass | 17:43.02 |
| Robin_Watts | actually, are we tilingtype 1 or 3 here ? | 17:44.24 |
| chrisl | 1 | 17:45.24 |
| Robin_Watts | maybe the issue is the origin? | 17:45.40 |
| chrisl | I don't think so. I hacked a test file for that, and it seems correct. | 17:46.22 |
| Robin_Watts | ok. | 17:46.34 |
| chrisl | That was my first thought, too! | 17:46.58 |
| Robin_Watts | So bear with me here. Do you have values for bbw/bbh/step.xx/step.yy ? | 17:47.12 |
| | (before 'correction') | 17:47.27 |
| chrisl | I'm in a different place in the debugger, give me a sec | 17:47.45 |
| | bbw = 8.33333302, bbh = 8.33349609, step_matrix.xx = 8.33333302 , step_matrix.yy = 8.33333302 | 17:50.38 |
| Robin_Watts | oh, wow, I wasn't expecting that. | 17:51.10 |
| chrisl | So, really, there's only the rounding to integer value happening | 17:51.54 |
| | And I don't understand *why* we do that | 17:52.19 |
| Robin_Watts | Both X and Y will be altered. | 17:52.27 |
| chrisl | Yes, sorry, it's just in the test cases we've got, only Y becomes really visible | 17:53.11 |
| Robin_Watts | I thought bbx and bbw were ints... | 17:53.37 |
| | bbw and bbh I mean. | 17:53.44 |
| chrisl | No, definitely floats | 17:54.30 |
| | My confusion is: we *have* to round to device pixels when we actually apply the tiling, so why do the rounding here? | 17:55.31 |
| Robin_Watts | We need to do the adjustment here otherwise what is rendered into the tiles ends up leaving gaps around the edge. | 17:57.07 |
| | The example I was looking at before had a step of 7.5, and a bbw of 8. | 17:57.24 |
| | So when rendered normally (with 0 fill adjust), only the first 7 pixels were drawn to. | 17:57.49 |
| chrisl | But we'd get the right result with that using your new code, and without the round to integer value, wouldn't we? | 17:59.19 |
| | Erm, hang on - the step and bbox can be different, so in your example, I'd expect a gap (at high enough resolution) | 18:01.47 |
| Robin_Watts | I'm confused. | 18:10.17 |
| chrisl | Well, it's not just me, then..... | 18:10.41 |
| Robin_Watts | I get the same values as you when rendering at 600dpi. | 18:10.54 |
| | So how come the pattern cell isn't roughly 8x8 pixels ? | 18:11.05 |
| chrisl | Isn't 8x8 in user space rather than device space? | 18:12.29 |
| Robin_Watts | If so, then the rounding to integers makes no sense at all! | 18:12.54 |
| chrisl | Erm, yeh! | 18:13.05 |
| Robin_Watts | Hmm. I get called later on for an 84x84 tile. | 18:13.20 |
| | Which seems more likely. | 18:13.26 |
| chrisl | As I said, we round to integers later when we actually *apply* the tiling, and that makes sense to me | 18:13.50 |
| Robin_Watts | We round that to a step of 83. Acrobat seems to be using 84. | 18:14.36 |
| | (Well, we're smaller than acrobat. | 18:14.55 |
| chrisl | Yes, so it makes sense that as we move away from the origin, we differ more and more from Acrobat | 18:15.43 |
| Robin_Watts | puts on his henry hat and goes looking for who changed this code in the past. | 18:16.03 |
| chrisl | should have done that before bothering Robin_Watts..... | 18:16.38 |
| Robin_Watts | It's an IGORism. | 18:18.22 |
| chrisl | Hmm, interesting - make metrics more "precize" by rounding to an integer? | 18:19.08 |
| | I wonder if this is a CPSI vs Acrobat difference | 18:19.27 |
| Robin_Watts | We guessed that a pattern size should always round up to allow | 18:19.45 |
| | a similar logics as for a clipping - "any part of pixel inside". | 18:19.47 |
| | But he's NOT rounding up! | 18:19.58 |
| | ray_laptop: Hey. | 18:21.56 |
| ray_laptop | darn. My laptop crashed while installing VS2008 SP1 | 18:21.59 |
| Robin_Watts | Could you do a test CPSI run of /ghostpcl/tests_private/pdf/PDF_1.7_FTS/fts_06_0618.pdf at 600dpi please? | 18:22.25 |
| | Oh, wait CPSI probably doesn't handle pdf files? | 18:22.52 |
| ray_laptop | Robin_Watts: OK. It'll take a few minutes (have to fire up that machine. | 18:23.01 |
| | Robin_Watts: why not ? | 18:23.08 |
| Robin_Watts | oh, ok, I thought it might be PS only. | 18:23.18 |
| ray_laptop | Actually I'm not sure -- but I'll try it | 18:23.40 |
| chrisl | Depending on the vintage, it might do a sort of conversion to PS and then run that | 18:24.03 |
| ray_laptop | chrisl: sort of like our opdfread.ps ? | 18:24.22 |
| chrisl | ray_laptop: yes, I think so | 18:24.51 |
| ray_laptop | Robin_Watts: you might want to look at what comes out of ps2write -- I should be able to run that | 18:25.03 |
| Robin_Watts | ray_laptop: That may be too late. | 18:25.20 |
| chrisl | I think it will, this code apparently influences pdfwrite (and therefore ps2write) output | 18:25.58 |
| ray_laptop | Robin_Watts: I'm retrying the install of SP1 (it didn't need to download again) | 18:26.07 |
| ray_laptop | keeps fingers crossed. | 18:27.05 |
| | and quits everything else in case that helps | 18:27.21 |
| chrisl | Robin_Watts: I find it deeply suspicious that if I remove that rounding of the matrix entries, and then do a pixel diff on our output and Acrobat's export to tiff, we match virtually pixel for pixel, but with the round in there, we're way off | 18:30.21 |
| Robin_Watts | Well, as has been proven, I don't understand this code. | 18:31.56 |
| | So if it's a CPSI vs Acrobat difference, I guess we have to decide which one we want to follow. | 18:32.21 |
| chrisl | Well, have a switch in there for CPSI compliance for just this type of situation | 18:32.46 |
| Robin_Watts | yeah. | 18:32.55 |
| | I can confirm that we get a match if we turn off the rounding. | 18:33.23 |
| chrisl | What surprised me was the accuracy of the match - we're *so* close! | 18:33.54 |
| Robin_Watts | Were you imagining we'd disable ADJUST_AS_ADOBE for non CPSI mode? | 18:34.01 |
| | Or just avoid the rounding ? | 18:34.11 |
| chrisl | My feeling is just avoid the rounding, that seems to be where the damage happens - but I want to experiment a bit more | 18:34.39 |
| | I'm not seeing significant differences with and without the rounding with the test file Igor attached to the bug, either | 18:37.38 |
| Robin_Watts | Let me try clusterpushing this then. | 18:37.53 |
| chrisl | Is it possible this was the source of the XPS problem that prompted your investigation before? | 18:38.46 |
| Robin_Watts | chrisl: No, that was a different thing. | 18:39.05 |
| | essentially XPS patterns should always be considered Type 2. | 18:39.19 |
| chrisl | Just a thought.... | 18:39.20 |
| Robin_Watts | OK, I've clusterpushed a small patch that only rounds in CPSI mode. Let's see what we get. | 18:41.01 |
| | I'd imagine *thousands* of tiny diffs. | 18:41.12 |
| | marcosw_ will love us. | 18:41.17 |
| chrisl | I think the cluster runs with CPSI mode true :-( | 18:41.24 |
| Robin_Watts | For .PS files, yes. | 18:41.31 |
| | but for .ps files or .pdf files, no. | 18:41.43 |
| | crufty hacks are us! | 18:41.58 |
| chrisl | :-) | 18:42.03 |
| Robin_Watts | I need Tea. | 18:42.35 |
| chrisl | Good idea! | 18:44.19 |
| Robin_Watts | now, I need Ray back. | 18:50.11 |
| chrisl | Robin_Watts: the four PS files that Igor lists as being problematic in 687581 when run directory to ppmraw show no differences with and without the rounding | 18:52.43 |
| | I wonder what: "Same problem when rendering re-distilled files" actually means..... | 18:53.32 |
| ray_xp | Robin_Watts: I sent the CPSI output to you and chrisl | 18:53.54 |
| | note that CPSI has it coming out upside down for some reason | 18:54.21 |
| chrisl | ray_xp: both of us is good, thanks! | 18:54.40 |
| Robin_Watts | ray_xp: Thanks. | 18:54.57 |
| ray_xp | np | 18:55.02 |
| Robin_Watts | I've dug myself out of the immediate hole I was in with the mupdf customer. | 18:55.14 |
| | So I can help out with 532 if you want. | 18:55.25 |
| ray_xp | Robin_Watts: if you want to look at the most recent profiles from Eric and see if you can spot anything, that would help | 18:56.29 |
| Robin_Watts | If you have it in hand, then clearly I'm happy to leave you to it, but if you want me to try a parallel attack on the image rotation thing, I can. Or I could look at the 2bit timings. | 18:56.33 |
| | OK. So I'll look at the new profiles; I'll look at the 2 bit ones, because the image rotation thing should help with the 1bit ones, right ? | 18:57.06 |
| chrisl | Robin_Watts: so, to me CPSI looks like it's applying the Postscript style "anchoring" and doesn't match Acrobat or our current code! | 18:59.21 |
| ray_xp | hurray!! my SP1 install finished | 19:00.23 |
| chrisl | ray_xp: let's hope it fixes your problem! | 19:01.10 |
| ray_xp | well, at least now the hot fix that mvrhel found goes in OK. | 19:01.49 |
| Robin_Watts | ok, so let's see what the cluster throws up, and then decide. | 19:01.52 |
| mvrhel | good deal | 19:02.00 |
| ray_xp | now I'll try the performance analyzer | 19:02.48 |
| ray_xp | holds breath | 19:02.52 |
| chrisl | Robin_Watts: I'm aware that various versions of Acrobat have tiled patterns slightly differently, so it's possible the same applies to CPSI.... | 19:03.32 |
| Robin_Watts | well, I suspect 'matching acrobat reader' is more important than 'matching CPSI' these days. | 19:04.18 |
| chrisl | I still think that for Postscript, it will be rare to have a "real" case that shows a significant difference, anyway - I doubt many people use CPSI as a benchmark for PDF | 19:05.56 |
| henrys | I have an HP PS RIP printer if you want me to give it a go. | 19:05.58 |
| | (not adobe) | 19:06.05 |
| chrisl | It's a PDF | 19:06.09 |
| henrys | oh right of course | 19:06.35 |
| chrisl | If we're really that bothered, I could probably write a PS job to test it, but I'm not sure it's worth it | 19:07.17 |
| ray_xp | mvrhel: THANKS A BUNCH !!! Profiling works for me now !!! :-) | 19:09.23 |
| mvrhel | great! | 19:09.33 |
| ray_xp | now to see if it will work with the customer's mess | 19:10.22 |
| chrisl | ray_xp: was there a reason Very Sleepy didn't work? | 19:11.41 |
| ray_xp | and to use with HEAD, I need to add a 'profile' target that links with the /Profile switch (apparently) so that I'll be able to run in 'Instrumentation' mode | 19:11.50 |
| Robin_Watts | ray_xp: The Visual Studio project already has a Profile mode, doesn't it? | 19:12.49 |
| ray_xp | chrisl: It would start collecting data on the wintrhead_emulator_task (where gs runs) and then after a few seconds get an error and die (losing everything it collected) | 19:12.59 |
| chrisl | ray_xp: oh, so the thread support is perhaps not fully mature, then! | 19:13.28 |
| ray_xp | Robin_Watts: Yes, I just noticed it. | 19:13.30 |
| Robin_Watts | ray_xp: Updating the Profile entry to use /Profile seems sensible; at the moment it's just release + symbols. | 19:13.54 |
| | I wonder if the Very Sleepy problem is down to the fact that their app requires certain things to be defined in the environment? | 19:14.27 |
| ray_xp | I'm doing a profile build now. I'll let you know what I need to do (unless mvrhel already knows) | 19:14.44 |
| mvrhel | just use the profile wizard | 19:15.43 |
| | after building the profile version | 19:16.09 |
| Robin_Watts | mvrhel: How does that work with nmake built versions? | 19:16.19 |
| ray_xp | mvrhel: I could only use it in 'Samplig' mode | 19:16.36 |
| mvrhel | you specify the executable, the parameters and the path in the wizard | 19:16.39 |
| ray_xp | Sampling | 19:16.43 |
| Robin_Watts | oh, release + symbols is enough for the profiler to work? | 19:16.55 |
| mvrhel | I build the profile version | 19:17.10 |
| | not sure what all it creates in that process | 19:17.24 |
| Robin_Watts | The profile version in the VS solution is just the release build with symbols kept in. | 19:17.48 |
| mvrhel | ray_xp: I have not tried the instrumentation version on this machine yet | 19:17.59 |
| Robin_Watts | It doesn't add the '/Profile' flag or anything. | 19:18.01 |
| mvrhel | ok. so there you have it | 19:18.12 |
| ray_xp | Robin_Watts: I'm trying that now | 19:18.13 |
| Robin_Watts | I suspect the /Profile flag would enable instrumented builds. | 19:18.19 |
| | but in my experience, instrumented builds are affected so much by the instrumentation, that I'd rather just use the sampler version. | 19:18.49 |
| | (that's not experience of this particular profiler, just profilers in general) | 19:19.02 |
| | 4 million calls to gs_type42_default_get_metrics seems a lot to me. | 19:19.44 |
| | as does 21 million calls to gs_find_compositor | 19:20.33 |
| chrisl | Robin_Watts: well, you were right about "lots of diffs" :-( | 19:21.42 |
| ray_xp | Robin_Watts: which file is that ? | 19:22.34 |
| Robin_Watts | J11_600_2bit is the sample. | 19:22.51 |
| | I'm downloading the test docs archive now. | 19:23.01 |
| ray_xp | Robin_Watts: yes, I noticed that J11 seems to spend a LOT of time in font stuff | 19:23.21 |
| | Robin_Watts: I think that was in one of my comments to Eric | 19:23.39 |
| | Robin_Watts: my email 2/3 9:38 (PST) | 19:24.52 |
| | I haven't tried that with the debugger to see what it's doing on that file | 19:25.36 |
| | maybe we can dump that to chrisl ;-) | 19:26.01 |
| Robin_Watts | Looks like the pdf interpreter is calling ztype43execchar a lot. | 19:27.51 |
| | 42, even. | 19:27.59 |
| chrisl | Are these Japanese test jobs? | 19:29.02 |
| Robin_Watts | Looks like it. | 19:29.46 |
| | But there are only 12 pages, and not *that* many glyphs. | 19:30.11 |
| | Maybe 1000-2000 glyphs overall. | 19:30.18 |
| chrisl | So, we could be seeing a lot of complex glyphs too big to cache | 19:30.25 |
| ray_xp | Hot diggity -- the profile with instrumentation WORKED !!! | 19:32.46 |
| Robin_Watts | ray_xp: How did you do the build? CFLAGS="/Profile" ? | 19:33.17 |
| ray_xp | Robin_Watts: no -- I just added the /PROFILE switch to the gswin.rsp in the LINK steps | 19:34.15 |
| | (modified the psi/msvc.mak) | 19:34.33 |
| Robin_Watts | Right. | 19:34.41 |
| ray_xp | Robin_Watts: I'll commit the change | 19:34.49 |
| mvrhel | is that something that we can have set up with the Profile build option in the VS solution? | 19:34.55 |
| Robin_Watts | mvrhel: Yes. | 19:35.26 |
| mvrhel | great | 19:35.30 |
| Robin_Watts | The VS solution calls a 'profile' target in the make files. | 19:35.37 |
| ray_xp | mvrhel: I just have an !if "$(PROFILE)"=="1" | 19:35.38 |
| Robin_Watts | so that can do... what ray said. | 19:35.45 |
| ray_xp | excellent. Just like having a real tool :-) | 19:36.12 |
| Robin_Watts | ray_xp: Will that work for GhostPDL targets too ? | 19:36.13 |
| ray_xp | Robin_Watts: don't see why not | 19:36.36 |
| Robin_Watts | The final link stage for them is in a different makefile. | 19:36.51 |
| ray_xp | Robin_Watts: right -- I'll do them all in one commit | 19:37.06 |
| | after I test it | 19:37.14 |
| Robin_Watts | common/msvc_top.mak I think. | 19:37.46 |
| ray_xp | I have to run an errand now -- bbiab | 19:38.03 |
| chrisl | Robin_Watts: is that J11 file the worst/only font hotspot (so far)? | 19:38.38 |
| Robin_Watts | chrisl: It's the only file reported to us in the latest batch of results for 2bit mode. | 19:39.53 |
| | which I assume means it's the only 2bit mode file that's still slower than before. | 19:40.06 |
| | I can't comment on the others yet, not having looked. | 19:40.32 |
| henrys | mvrhel:are you looking at PWTTQ1CC.pdf? | 19:41.06 |
| chrisl | Robin_Watts: I don't see why the output bit depth would affect the interpreter's font handling | 19:41.19 |
| Robin_Watts | chrisl: Indeed. I just calls 'em as I sees 'em. | 19:41.50 |
| chrisl | Robin_Watts: oh, unless this is falling back to Ray's banding by reinterpreting the PDF fallback? | 19:42.29 |
| mvrhel | henrys: no. I am not | 19:54.31 |
| Robin_Watts | PWTTQ1CC.pdf is the one with the rotated image in. Last I heard, Ray was working on that. | 19:55.00 |
| mvrhel | I chatted with ray about it 2 days ago and he was pushing forward with a solution that we talked about | 19:55.19 |
| | actually yesterday I talked with him about it | 19:55.30 |
| henrys | okay the shark profile shows it spends all its time in your new image/ht code - which I assume they don't have | 19:57.05 |
| mvrhel | right. they dont have that | 19:57.20 |
| henrys | I also noticed (by accident) it slowed down about 15% going from 9.01 to current. That has nothign to do with the current exercise but was a bit alarming. | 19:58.42 |
| mvrhel | when halftoning? | 19:59.13 |
| henrys | yes i'm using 1 bit (pbmraw) | 19:59.34 |
| mvrhel | I suppose that is possible. If we are doing these small vertical strips we end up essentially doing calls to render_mono that are 1x1 bits as we loop over the y values in the band. the fast threshold stuff is not going to be too fast in that case | 20:00.58 |
| | the fix that ray is working on should take care of this | 20:01.15 |
| henrys | okay makes sense | 20:01.48 |
| Robin_Watts | Gah. I can't get any debugging printfs out of their simulator. | 20:02.14 |
| | Anyone know what function to call offhand? | 20:02.29 |
| | dlprintf() is going nowhere. | 20:02.34 |
| chrisl | It should still print into the backchannel window | 20:02.58 |
| Robin_Watts | But the "*** Warning: GenericResourceDir doesn't point to a..." message is coming out OK, so clearly at least one of them is working. | 20:03.12 |
| | chrisl: Not unless I'm going blind. | 20:03.24 |
| chrisl | Hmm, I've mostly been going from the PS world - you could look up how zprint() is doing it | 20:04.17 |
| Robin_Watts | ok, vanilla printf works. | 20:08.25 |
| chrisl | Hmm, maybe they don't define DEBUG on their debug build...... | 20:08.58 |
| Robin_Watts | More likely they have stderr redirected somewhere else. | 20:09.49 |
| | I'm seeing 8K calls to that function, not 4 million... | 20:11.20 |
| chrisl | To the Type 42 metrics function? 8K would seem more plausible | 20:16.06 |
| Robin_Watts | indeed. | 20:17.47 |
| chrisl | Robin_Watts: even reinterpreting to achieve banded rendering, it's hard to imagine going from 8K to 4M | 20:18.51 |
| | Robin_Watts: I've had a quick look through some of your bmpcmp results - a lot are tiny variations, a few PDFs are closer to Acrobat. If you want to just leave it to me, I'll check through properly tomorrow. | 20:21.32 |
| Robin_Watts | chrisl: That bmpcmp should have run with a threshold and a window. | 20:22.13 |
| | So hopefully lots of diffs were excluded. | 20:22.26 |
| chrisl | It probably did. There are a few PCL/PXL tests that look "worse", but only at 75dpi - they appear at 300dpi. | 20:24.14 |
| | I mean, the don't appear at 300dpi | 20:24.31 |
| | This is why I need to leave any more until tomorrow - I'm starting to get a headache, and melting brain syndrome :-( | 20:25.18 |
| Robin_Watts | chrisl: I know that feeling. | 20:25.56 |
| chrisl | Robin_Watts: So, I'll let Len know we're testing a fix, and go through the results properly tomorrow (I'll do my own clusterpush, so you can do others if you need to). You can ping me if you want me to look at the J11 font thingy | 20:27.58 |
| Robin_Watts | chrisl: Thanks. | 20:30.05 |
| | I suspect I'm going to send a message back querying the profile; if we can't trust the results the profiler is giving us, I'd like to know. | 20:30.31 |
| | I suspect it's a device vs simulator difference, which is bad news for us... | 20:30.50 |
| chrisl | I seem to remember, at least previously, the simulator didn't limit memory use to the same level as the target, or maybe even at all. That could be huge if the simulator is caching stuff that the target is having to discard. Worth checking with Ray about that, though. | 20:32.55 |
| | Right, I'm off - 'nite all...... | 20:37.40 |
| Robin_Watts | night. | 20:37.45 |
| mvrhel | bbiaw | 21:36.52 |
| | Forward 1 day (to 2012/02/10)>>> | |
IRC Logs