| | <<<Back 1 day (to 2014/04/15) | 2014/04/16 |
| Guest51947 | Hi | 03:51.53 |
| | I have trouble opening pdf using open buffer method in the Mupdf latest 1.4 version | 03:53.05 |
| | In 1.3 it works well | 03:53.22 |
| ammo8600 | How can i convert EPS to SVG | 07:41.56 |
| kens | Use the SVG device | 07:42.08 |
| ammo8600 | I cant find the documentation | 07:42.40 |
| kens | Where have you looked ? | 07:42.54 |
| ammo8600 | ghostscript site | 07:43.07 |
| kens | The documentation is supplied with Ghostscript as HTML files in the directory ghostscript/doc | 07:43.35 |
| | That said,the svgwrite device is (I think) deprecated | 07:44.15 |
| | So there is no documentation on it | 07:44.25 |
| | Hmm seems we put it back in again in 2012 | 07:45.29 |
| | However, that being said, it doesn't seem to be built in the current Windows code. chrisl ping ? | 07:46.48 |
| ammo8600 | so whats the point | 07:49.05 |
| kens | What operating system are you using ammo8600 ? | 07:49.07 |
| ammo8600 | windows | 07:49.15 |
| kens | THen you will have to build from source I think and add the device. | 07:49.49 |
| | I'll ask chrisl about it when he comes back | 07:49.57 |
| | Also, as noted in the commit, the SVG device is flaky and not really maintained, its been added back in so that people who want to can experiment with it, and hopefully improve it. I wouldn't plan on using it for anything significant | 07:51.06 |
| ammo8600 | any other library that works | 07:53.01 |
| kens | Given that EPS is written in PostScript you will need a full PostScript interpreter in order to process it. The quation 'what open source PostScript itnerpreters are there ?' has been asked on various forums a number of times, and there seem to be 2; Ghostscript and xpost. xpost doesn't (to the best of my knowledge) output SVG. | 07:54.46 |
| | So, in short, no. | 07:54.51 |
| | You could try loading it into Photoshop if you have a copy | 07:55.15 |
| chrisl | kens: Sorry, phone call.... | 08:13.26 |
| kens | No problem, he's gone off now anyway. Looks like we don't build the svgwrite device into the windows binary is all. | 08:13.57 |
| chrisl | Well, it barely works, and mupdf is now the solution favoured - which wouldn't work for him either, so..... | 08:14.38 |
| kens | Yeah I was just typing more or less that, and its what I said to him :-) | 08:14.54 |
| | Here's a good one for you, that just bit me...... | 08:15.16 |
| | If you do a rectfill, it maps directly to the device's fill_rectangle() method | 08:15.35 |
| | And therefore bypasses the pdf14 compositor, so the transparency doesn't work. | 08:16.02 |
| chrisl | Er, eh? Surely it should call the pdf14 device's fill_rectangle() ? | 08:16.36 |
| kens | Apparently not | 08:16.43 |
| chrisl | That sounds like a bug to me! | 08:17.11 |
| kens | And if I replace my 'rectfill' with a constrcuted and filled path, the transparency works.... | 08:17.12 |
| | It may be a limitation of the current device architecture. | 08:17.46 |
| chrisl | There is a pdf14_fill_rectangle() so it really *should* work | 08:18.11 |
| kens | I can state with some authority that it doesn't :-) | 08:18.32 |
| chrisl | Is this with a clist or not, or both? | 08:18.46 |
| kens | Haven't tried with a clist | 08:18.58 |
| | but if you look in ghostpdl/gs/examples/transparency_example.ps you'll see it mentioned | 08:19.32 |
| chrisl | So we *know* about this, and just left it?? FFS!! | 08:20.06 |
| kens | Apparently so, yes | 08:20.16 |
| | It was, shall we say, surprising to me | 08:20.38 |
| | Trying to figure out why my strokes and text were all composited, but my rectangular fill wasn't | 08:21.17 |
| chrisl | Well, it looks to me like the code is there for it to work, so it's not simply "missing", something is going wrong | 08:21.20 |
| kens | I cna have a quick play with it before I go out, I'd just like to see my cluster resutls first | 08:21.47 |
| | Oh that's not good | 08:22.16 |
| | It totally failed to build | 08:22.24 |
| | Ah no it didn't | 08:22.34 |
| | I just got a shed load of warnings | 08:22.41 |
| | Oh there's a message I've never seen form the cluster before "The following files had a 5% or greater increase in intermediate pdf/ps file size" | 08:23.28 |
| | THat is (of course) on PostScript output from a couple of Sumatra files with transparent annotations, so not surprising | 08:23.56 |
| chrisl | Oh, does the PDF interpreter never call rectfill? That might make it almost forgiveable..... | 08:24.39 |
| kens | It looks like the PDF interpreter takes care not to | 08:24.53 |
| | The only rectfill in there is the one I commented out in my new code | 08:25.23 |
| | Actually no, there is another, but its in the annotation code and it doesn't handle transparency in that bit. | 08:25.54 |
| chrisl | So, rather than fix the compositor, we hack about the interpreter..... | 08:26.29 |
| kens | Looks that way, yes | 08:26.38 |
| | If it was just the 're' operator I wouldn't mind, but it means nobody can use rectfill i the PDF interpreter for any purpose, if they expect transparency to work | 08:27.24 |
| chrisl | It also begs the question, why use rectfill in transparency_example.ps at all? | 08:28.02 |
| kens | It doesn't, it constructs the rectgangle manually, presumably as an example of how to do rectangular fills, and to document that you can't use rectfill. | 08:28.42 |
| chrisl | No, it uses rectfill, but redefines it so it doesn't use the operator.... | 08:29.47 |
| kens | Yes, that's what I mean | 08:29.55 |
| chrisl | I suppose you could add a .pdfrectfill | 08:30.13 |
| kens | shudders | 08:30.23 |
| | Well it looks like my transparency changes are OK so I'm going to commit that. Some files are now detected as 'transparent' which weren't before, leading to some small rendering differences. I think there's a fair number of annotaiton types where we don't apply the actual transparency though | 08:32.26 |
| chrisl | So, pdf14_fill_rectangle() is called from zrectfill() so I've no idea why it doesn't work..... | 08:33.48 |
| kens | Hmm, that does seem odd. Maybe I should hand it to Michael | 08:34.05 |
| chrisl | I really think it should work, or be made to explicitly fail if called | 08:34.52 |
| kens | I'll take a quick poke in a minute | 08:35.24 |
| | Just writing up my commit message | 08:35.36 |
| | I suppose I'd better be extra careful about typos | 08:35.46 |
| chrisl | It ultimately gets to pdf14_mark_fill_rectangle() which does a load of "interesting" calculations - which would be a waste of time if it doesn't actually apply any transparency! | 08:36.25 |
| kens | Well it definitely didn't for me, but give me a minute or two | 08:36.51 |
| chrisl | kens: you have removed the debugging lines for your actual commit? | 08:37.38 |
| kens | Oh yes :-) | 08:37.45 |
| | chrisl in fact those debugging lines don't form part of the commit, they are for a different bug and that file isn't going to be commited at all | 08:40.13 |
| | Hmm, the example file goes through the clist for me, that's a surprise | 08:44.19 |
| chrisl | At what resolution? | 08:44.43 |
| kens | and cdev->pdf14_needed is flase, so that won't work properly | 08:44.57 |
| | chrisl I'm using the display device, 72 dpi ? | 08:45.05 |
| | ah, I wonder if this is the erasepage | 08:46.02 |
| | yeah it is | 08:46.20 |
| chrisl | It didn't use the clist at 100dpi for me | 08:47.26 |
| kens | chrisl my command line is "gswin32 trasnparency_example.ps" | 08:47.55 |
| | If I put back the rectfill redefinition then it works | 08:48.40 |
| chrisl | I seem to get basically the output whether rectfill is redefined or not..... | 08:49.30 |
| kens | Presumably because you aren't triggering the clist for some reason | 08:49.49 |
| | OK... If I set -r72 then I get to the pdf14 compositor | 08:50.49 |
| | But the result is still wrong | 08:51.08 |
| chrisl | Ah, not sure what happened there - I do see teh difference with/without the rectfill redefinition, with or without clist | 08:52.36 |
| kens | OK then at least we are consistent :-) | 08:52.52 |
| | THe first rectangle is 100% opaque anyway, so I neded to bypass tht one | 08:53.11 |
| | In fact it looks like both the first 2 are opaque | 08:53.32 |
| | I think I'm going to make a new simpler file# | 08:53.42 |
| chrisl | I think that either the pdf14 compositor should be fixed, or *at least* gs_rectfill() should be changed to fall back to explicitly constructing the path and filling it if transparency is involved | 08:55.20 |
| kens | Well I agree something needs to be fixed, having to redefine (or not use) rectfill is nuts | 08:55.45 |
| | well it looks like src_alpha is incorrect, its 255. | 08:57.14 |
| | Looks to me like the code at the start of do_fill, which calculates abits, is possibly relevant | 08:58.46 |
| | Oh, or perhaps not | 08:59.00 |
| | that seems to be from GraphicsAlphaBits | 08:59.17 |
| chrisl | Yes, that's for the poorly names AlphaBits...... | 08:59.35 |
| kens | OK so eventually the generalised path fill code detects that its a rectangle and short circuits to gx_fill_rectabgle_device_rop, so it *must* be possible to have rectfill work properly | 09:02.34 |
| | I give up, I'm going to open a bug for Michael | 09:04.48 |
| | for a couple of hours, back later. | 09:18.08 |
| | Hmm, half my text went AWOL oO | 09:18.23 |
| | I'm off out for a couple of hours, back later | 09:18.35 |
| paulgardiner | Any body in a position to make a small change to a PDF file, or better point me at a copy of Acrobat I can use? | 11:08.10 |
| pedro | paulgardiner: I think either Robin or Henry mentioned yesterday there's a copy of Acrobat on casper somewhere. Should be in the logs | 11:12.19 |
| paulgardiner | Oh okay. Thanks peds. | 11:13.30 |
| pedro | finds the reference | 11:14.31 |
| | sorry - Robin said he and most folks have Acrobat Pro | 11:14.51 |
| paulgardiner | Ta. I'll give him a try | 11:16.11 |
| kens | paulgardiner : you still need a PDF file modified ? | 11:42.49 |
| paulgardiner | I do. Just a couple of Picsel logos replaced by Artifex's | 11:43.26 |
| kens | I can have a go if you point me at the bits needed | 11:43.40 |
| paulgardiner | Great. Thanks kens | 11:43.58 |
| | I'll upload the file to casper to save the need to checkout sot, which would take ages | 11:44.31 |
| kens | SOunds good to me :-) | 11:44.39 |
| | paulgardiner : which file is it ? I'm assuming its in your home directory | 11:48.06 |
| paulgardiner | kens: just uploaded print-room-ui.png | 11:48.28 |
| kens | aha OK | 11:48.33 |
| paulgardiner | Also in there artifex.png, which is the logo I've been using elsewhere, but you may have a better one | 11:49.18 |
| kens | I certainly don't have a better one, I have no log at all I think | 11:49.33 |
| | Thoguh I might be able top steal one from another document | 11:49.42 |
| paulgardiner | That one is from our web site | 11:50.05 |
| kens | OK well let me see how it goes | 11:50.15 |
| | I don't se the print room PNG file though | 11:50.33 |
| paulgardiner | Sorry. I meant to type print-room-ui.pdf | 11:51.10 |
| kens | Aha, the PDF I have. | 11:51.18 |
| | SO you want the P* logo replaced with Artifex ? | 11:51.28 |
| paulgardiner | yes please | 11:51.38 |
| kens | OK give me a minute | 11:51.46 |
| | Hmm, well I've changed it, let me upload it and you can critique it. | 11:55.09 |
| paulgardiner | excellent | 11:55.32 |
| kens | OK it won't let me write to your home directory (unsurprisingly) so I'll put it in mine | 11:55.58 |
| paulgardiner | :-) | 11:56.12 |
| kens | OK its ther now, same name +mod | 11:56.27 |
| paulgardiner | s/.png/mod.png/ ? | 11:57.00 |
| kens | Err I meant + "-mod.pdf" | 11:57.21 |
| | so print-room-ui-mod.pdf | 11:57.32 |
| | One problem is the sahape of the logos, the original is very wide, the Artifex one is basically square | 11:58.06 |
| | and quite a lot smaller | 11:58.15 |
| paulgardiner | Yeah, ta that;s what I thought but autocorrect keeps changing pdf to png... except I don't have autocorrect, so I guess it's just me! | 11:58.16 |
| kens | :-D | 11:58.25 |
| | I can't find a better Artifex logo anywhere here | 12:00.30 |
| paulgardiner | Looks good to me. I think I've scaled it up a bit where I've used it but I think it'll do nicely | 12:01.43 |
| kens | OK if you're happy then that's fine, if you cna find a bigger log I cna use that instead, but I don't seem to have one here | 12:02.10 |
| paulgardiner | Yeah, saved me a lot of hassle, thanks. | 12:02.53 |
| kens | You're welcome, any time | 12:03.00 |
| henrys | kens:the svg prescription is to use mupdf | 12:32.33 |
| kens | henrys, won't work for EPS input :-) | 12:32.47 |
| henrys | and pdfwrite if needed | 12:32.54 |
| kens | I suppose one could go EPS->PDF->SVG but that's a horrifying thought | 12:33.08 |
| henrys | less horrifying than a good svg device in ghostscript | 12:33.40 |
| | kens:anyway that's what we agreed to when we got rid of svgwrite if you want to resurrect the issue, I'll add it to the agenda. | 12:35.52 |
| kens | Nope, I was perfectly happy with the 'its depecated' answer | 12:36.13 |
| | I'd probably have thought about it harder but the guy was irritating me a bit | 12:36.28 |
| | And I was busy with transparency | 12:36.39 |
| henrys | pedro:are we good with good now ? ;-) | 14:58.45 |
| mvrhel_laptop | brb | 15:09.14 |
| pedro | henrys: pretty much thanks - at least they've confirmed that we're doing the right things now. | 15:10.08 |
| | should hopefully be able to run the iOS build today once I have the server talking nicely with Good's server | 15:12.01 |
| henrys | pedro: they often speak in "Good" jargon and I've no clue what they are saying, but the last transmission could be parsed. | 15:12.12 |
| pedro | indeed :) | 15:12.22 |
| pedro | doesn't like Windows Server. I forgot how much of a pin it is trying to get things set up to work on the domain controler itself | 15:13.47 |
| | should perhaps just have crated 2 VMs rather than one ... | 15:14.01 |
| | my wireless keyboard (or fingers) are dropping a lot of characters today :( | 15:17.21 |
| ray_laptop | chrisl: I have a question about a text issue (cust 532's performance issue) | 15:34.55 |
| chrisl | ray_laptop: I've just been reading some of the thread.... | 15:35.55 |
| ray_laptop | chrisl: I am seeing exactly the expected number of invocations of FAPI_do_char on page 1 of the file (based on analysis of the contents) -- 85 invocations out of 5K characters printed | 15:36.18 |
| mvrhel_laptop | nice reduction on the color mapping calls ray_laptop | 15:36.42 |
| ray_laptop | chrisl: but on page 2, it seems that it has thrown away the cache and it does another 84 calls, then 80 more on page 3 ... | 15:37.33 |
| chrisl | ray_laptop: yes, that's the way it works - fonts for each page are loaded into local VM, so the end of page restore empties the cache | 15:38.27 |
| ray_laptop | I don't know how much that is costing us, but do you know WHY we are dumping (or otherwise invalidating) the cache on each page | 15:38.36 |
| chrisl | See above | 15:38.48 |
| ray_laptop | chrisl: the fonts are NOT being loaded on each page! | 15:39.19 |
| | They only load once on page 1 | 15:39.37 |
| chrisl | Are these embedded fonts, or built-in ones? | 15:40.10 |
| ray_laptop | chrisl: do we explicitly empty the font cache on page restore ? | 15:40.14 |
| | chrisl: yes. TimeNewRoman (UFST) | 15:40.27 |
| chrisl | I think we are creating new font objects for each page, and destroying them at the end of the page, hence the cache will be emptied | 15:41.50 |
| ray_laptop | mvrhel_laptop: I ran a regression on the change to the color functions against HEAD and it looks good. I'll push the patch to my repo for you to review | 15:42.26 |
| mvrhel_laptop | ray_laptop: ok | 15:42.40 |
| ray_laptop | chrisl: How can I tell if that is going on ? Or can you look with stock 9.1x gs (while I keep looking at other things). It may not be worth much (I don't have the FAPI_do_char timings yet), but even .2 seconds per page with the color changes made a 10 second diff out of the 50 seconds we are looking for | 15:44.24 |
| chrisl | ray_laptop: sorry phone call | 15:47.10 |
| ray_laptop | chrisl: np. I expect another call from Len shortly as well. :-( | 15:47.35 |
| chrisl | As far as I know, the PDF interpreter has worked that way for a very long time - I've never seen it do anything different | 15:47.57 |
| | ray_laptop: I guess you could add a bit of PS to print out whether the font is in local or global VM | 15:51.34 |
| ray_laptop | chrisl: OK, I _am_ seeing gs_font_finalize calling gs_purge_font_from_char_caches_forced during a restore | 15:52.58 |
| chrisl | ray_laptop: that's what I would expect, yes | 15:53.28 |
| ray_laptop | So I need to see if I can keep the font around, or not purge and recognize that it is the same fonr. | 15:53.55 |
| chrisl | ray_laptop: you can't do that for embedded fonts, you'll need to alter the PDF interpreter to spot when it's using a "built-in" font, and load it into global rather than local VM | 15:55.01 |
| | ray_laptop: considering how many places the PDF interpreter "loads" fonts, that's going to be quite a big task | 15:55.41 |
| | ray_laptop: actually, I'm not sure you can even safely do it for built in fonts........ | 15:56.41 |
| ray_laptop | chrisl: I'm looking at pdffindcachedfont and it seems to handle local or global fonts returned from 'findfont' (that's what I was going to zap since that is only used by PDF for non-embedded fonts) | 15:58.38 |
| chrisl | ray_laptop: the problem is that routine rebuilds the font a'new, for things like Widths arrays and such | 15:59.56 |
| ray_laptop | chrisl: we have two separate caches in PDF for those 'adjusted' fonts -- one global VM one local. | 16:00.45 |
| chrisl | ray_laptop: AIUI, we don't use the global one, as we can't safely cache adjusted fonts between pages | 16:01.22 |
| | ray_laptop: I see no reason why text in 9.x should be slower than 8.7x for these cases | 16:04.25 |
| | ray_laptop: what version are 532 working with now? | 16:05.09 |
| kens | Have we tetsed a stock GS ofg that vintage to see ? | 16:05.12 |
| ray_laptop | chrisl: That's the first thing I did (but on my computer, an x86) their target processor is MUCH slower | 16:05.55 |
| chrisl | kens: not specifically, but as they are using UFST with both versions, both versions are using FAPI, in one or other form | 16:05.58 |
| ray_laptop | kens: (sorry that reply was for you) | 16:06.06 |
| | chrisl: they are based on 9.06 | 16:06.18 |
| | kens: on that test, 8.71 and 9.06 are virtually identical on my x86 | 16:06.48 |
| | and the 9.14 is slightly faster | 16:07.03 |
| | but not much (2% or so, so hard to measure) | 16:07.26 |
| chrisl | ray_laptop: given that both versions are using UFST/FAPI it's hard to see why there should be such a difference in the font handling | 16:07.55 |
| ray_laptop | chrisl: yep, I agree. Just grasping at straws. I'm continuing to try and look at things like the number of times through the interpreter (comparing) to see if it might be something in the PDF interp that changed | 16:19.41 |
| chrisl | ray_laptop: can you put the test file somewhere for me, I don't seem to have it | 16:20.19 |
| | ray_laptop: the risk we run is that there are PDFs out there with fonts with different characteristics but the same name, used on different pages - if we cache between pages, we risk not spotting a different Widths array, or different Flags, etc....... | 16:22.17 |
| Robin_Watts | ray_laptop: I'm sure you've thought of this and probably discounted it, but just in case... | 16:25.25 |
| | In some vaguely recentish version of gs we tweaked the clist compression of glyph bitmaps. | 16:25.56 |
| | Previously the padding bytes were compressed, now they are not. | 16:26.18 |
| | Also, I have a vague memory of us changing what compression methods were used for the bitmap glyphs. | 16:26.40 |
| chrisl | IIRC, 532 fiddle with glyph compression in the clist...... | 16:27.06 |
| | So possibly worth checking they are reapplied their patch to 9.06? | 16:28.10 |
| ray_laptop | Robin_Watts: I'll make sure that stuff is in, but I would expect that to show up in the gx_image_cached_char timing and 9.06 is only .6 seconds slower for all 50 pages | 16:32.21 |
| Robin_Watts | ray_laptop: Sure. I'm not really following your bug. It just occurred to me, and I thought better to mention it and have it be useless than to sit on it and have it waste hours of your time. | 16:33.19 |
| ray_laptop | Robin_Watts: np. I appreciate your mentioning it, and I _will_ check to make sure on that patch | 16:34.20 |
| | Robin_Watts: the other thing is that Len told me that they had put in the 6th gen performance patches, but it wouldn't hurt to double check them on that ;-) | 16:35.21 |
| chrisl | ray_laptop: can you put the test file somewhere I can get it? | 16:36.08 |
| ray_laptop | chrisl: it's attached to the email from Len on 4/2. The WWTTN1CT_PDF_1_7.pdf is the primary one we are working with | 16:37.50 |
| | email subject "Performance Issue". Let me know if you don't have that email, and I'll send it along | 16:38.28 |
| chrisl | Ah, got it, I didn't spot the different subject line..... | 16:39.19 |
| ray_laptop | chrisl: OK. | 16:41.32 |
| chrisl | Hmm, strange, creating the font into global VM doesn't result in it being reused, either..... that's odd | 16:46.27 |
| | ray_laptop: I note that although we have .pdforigfontcache_g, .pdforigfontcache_l and pdffindcachedfont, we *never* actually call pdfaddcachedfont..... | 16:57.11 |
| kens | OK goodnight all | 16:58.15 |
| ray_laptop | mvrhel_laptop: I hope you don't mind, but I took the bug 695163 that had to do with transparency. | 17:06.13 |
| | kens had spotted that when working on something else, and I figured you have a full plate on other stuff. | 17:06.55 |
| mvrhel_laptop | ray_laptop: no I don't mind. I am drowning in mouse capture/release fun right now. about ready to take a hammer to this machine | 17:07.12 |
| ray_laptop | mvrhel_laptop: OK. Have fun :-/ | 17:07.40 |
| chrisl | ray_laptop: I'm going to be finishing for the day soon - if you need me to look into anything for Len's performance issue, just let me know | 17:08.10 |
| ray_laptop | chrisl: ok. thanks. If Len gets FAPI_do_char timings, we'll know whether or not better font cache will be helpful | 17:26.24 |
| | as it is we are only doing < 90 glyph render actions per page of 5K characters | 17:27.01 |
| Robin_Watts | ray_laptop: Surely that means that either the render actions must be MUCH slower to make a noticable difference, or the problem must be in the replaying of the rendered glyphs? | 17:28.12 |
| chrisl | ray_laptop: it is possible that some of the 532 customisations in the FAPI code are conflicting with the updates between early 9.xx and 9.06 - but that seems a stretch... | 17:29.06 |
| ray_laptop | Robin_Watts: the gx_image_cached_char is where we "replay" the rendered glyphs, and that is NOT the problem (.6 seconds total for all 50 pages) | 17:34.49 |
| | chrisl: I agree. It is not likely | 17:35.10 |
| Robin_Watts | So it must be a slowdown within those 90 glyph render actions? | 17:35.31 |
| chrisl | Looking at the numbers Len just sent, I don't think so - unless I'm misreading the numbers (which is possible) I think removing FAPI_do_char() entirely would not get back the time | 17:37.01 |
| | I *really* wish they had a proper profiler on the target - it astonishes me they don't | 17:42.38 |
| ray_laptop | chrisl: yeah, even gprof would be better than their 'hprof' | 17:44.40 |
| chrisl | I don't really understand why they can't use gprof on at least the higher spec machines. | 17:45.51 |
| ray_laptop | the problem with gprof is that they have threads, not processes, so the times can be seriously impacted by other threads | 17:46.10 |
| chrisl | True, but it would be better than guessing where the time goes, and then trying to confirm it :-( | 17:47.04 |
| Robin_Watts | ray_laptop: I have the bare bones of a profiler that they could use. | 17:47.39 |
| | I wrote it for the Nintendo DS. It's dead simple. | 17:49.05 |
| | It relies on being able to get a ticker event from somewhere. | 17:50.22 |
| | spanners: You up for a Picsel fonty question ? | 17:50.59 |
| chrisl | There's a fairly simple hack to get gprof working better with threads.... I suspect the problem is more organisational than technical | 17:51.59 |
| | I'm starting to get a headache, so I'm stopping now - ray_laptop as I said, if you need me to look at anything, just let me know | 17:55.17 |
| ray_laptop | hmm... 9.06 makes 10% more loops through the interpreter loop on each page. Now what to do about that ??? The changes in the PDF interp are pretty extensive :-( | 18:17.47 |
| Robin_Watts | presumably because it's doing more stuff to get more stuff correct. | 18:34.52 |
| chrisl_away | Remember we're running *loads* of stuff in the PDF interpreter in stopped contexts to try to "carry on regardless", which we didn't in the 8.xx code. | 18:40.55 |
| ray_laptop | chrisl_away: Len sent the results. We are spending a total of 10.8 seconds in FAPI_do_char, so improving the font cache _would_ have an effect. Please sleep on it, and we'll talk tomorrow | 18:44.38 |
| spanners | Robin_Watts: Sure (Picsel fonty Q) | 21:01.26 |
| | Forward 1 day (to 2014/04/17)>>> | |
IRC Logs