| | <<<Back 1 day (to 2012/11/22) | 2012/11/23 |
| tor8 | Robin_Watts: ping | 11:04.39 |
| Robin_Watts | tor8: pong | 11:37.15 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=0901eea3e35d8ca7014f21e3ae9270d8d302df66 | 11:37.17 |
| Robin_Watts | eeps at the gamma code. | 11:40.37 |
| | FZ_BLEND is supposed to be nice and fast :( | 11:40.55 |
| | actually, we could do a version that used a 256 byte lookup table. That wouldn't be TOO bad. | 11:42.00 |
| tor8 | Robin_Watts: sorry, went for lunch | 12:57.45 |
| Robin_Watts | np. | 12:57.56 |
| tor8 | Robin_Watts: yeah, the gamma code is proof of concept. I intend to make a fixed point lookup-table based version. | 12:57.59 |
| | just wanted to see the visual results first | 12:58.10 |
| Robin_Watts | I'm remotely debugging multicore mupdf problems with Romania at the moment. | 12:58.24 |
| | tor8: yeah, I understand. | 12:58.31 |
| tor8 | line art looks a fair bit nicer. text is .. unusual. it makes everything look a lot lighter :( | 12:58.38 |
| | but it does become crisper | 12:58.49 |
| Robin_Watts | I have some scan converter speedups, but I'm getting cluster differences that I need to investigate. | 12:59.14 |
| tor8 | yeah, I briefly looked at the scan converter optimizations | 12:59.33 |
| | are the boost significant? it does add a fair amount of extra code in an already fairly tricky area :( | 12:59.58 |
| | ah, good luck with the debugging! | 13:00.09 |
| Robin_Watts | tor8: yes, very significant. | 13:00.11 |
| tor8 | Robin_Watts: good, I guess :) | 13:00.20 |
| | we could probably drop to 4 bits of AA without anyone noticing | 13:00.30 |
| | as a default | 13:00.36 |
| | have you had a chance to look at the results of the gamma branch yet? | 13:00.45 |
| Robin_Watts | tor8: I haven't. | 13:01.29 |
| | Ass. Inline image loading gets the contexts confused in multithreaded rendering. | 13:15.24 |
| | We swap from the device context onto the document context, and the try/catches then implode. | 13:15.50 |
| tor8 | Rats. | 13:23.10 |
| | Robin_Watts: new gamma code with tables on tor/gamma, should be less atrociously slow | 13:23.26 |
| Robin_Watts | The solution is to pass more fz_context *'s around, but I wonder how far that will spread :( | 13:23.44 |
| tor8 | 12 bits is the minimum required to not lose information on a round trip | 13:23.47 |
| | Robin_Watts: image loading should be done on the document thread, regardless | 13:24.20 |
| | so that's a possible show stopper unless we rip out the fz_context from the document and add locks everywhere. I hate locks. | 13:24.42 |
| Robin_Watts | tor8: Why? | 13:24.54 |
| tor8 | confusing and error prone | 13:25.00 |
| Robin_Watts | Why should image loading be done on the document thread? | 13:25.14 |
| tor8 | give me channels and pass immutable data between threads | 13:25.24 |
| | Robin_Watts: if it needs to dig up the image from disk | 13:25.32 |
| Robin_Watts | OK, for inline images, the data is in a buffer. | 13:25.46 |
| tor8 | otherwise, it should be completely decouplef from the fz_document | 13:25.51 |
| Robin_Watts | cos we read the buffer in before we start to execute it. | 13:26.11 |
| tor8 | right. so where does the fz_document get into the picture? I'd thought that from the fz_device calls it's too late to end up back in fz_document space | 13:26.41 |
| | though you may have violated that thought with your image loading callbacks... | 13:27.01 |
| Robin_Watts | The particular case that is going wrong is multithreaded rendering of a document with type 3 fonts. | 13:27.51 |
| | Where the fonts contain an inline image. | 13:28.07 |
| tor8 | a pretty common case | 13:28.15 |
| | right, so the type3 callback has saved a document context | 13:28.50 |
| Robin_Watts | When we call pdf_load_inline_image, it gets the context from csi->xref | 13:29.01 |
| tor8 | how about rejigging the type3 fonts to create a display list per glyph instead? | 13:29.04 |
| | at load time | 13:29.07 |
| Robin_Watts | sorry, from xref->ctx | 13:29.19 |
| | I'm hoping that just a few more passings of the context should be enough. | 13:29.43 |
| tor8 | because the t3 callbacks get called from other threads and that drops us back in the document loader, which isn't thread safe | 13:29.48 |
| | though it probably is, because the t3 content stream is preloaded. but what happens if it uses a non-inline image? | 13:30.10 |
| | then you'll be calling fz_document from multiple threads at potentially the same time | 13:30.31 |
| Robin_Watts | yeah :( | 13:30.46 |
| tor8 | we should pre-interpret the t3 glyphs to display lists | 13:30.58 |
| | that'll remove a bunch of callbacks and a lot of icky design :) | 13:31.08 |
| Robin_Watts | The customer that wants this is still on 1.0 :( | 13:31.34 |
| tor8 | Robin_Watts: shouldn't be too much trouble to back-port. we haven't touched the font stuff too much since 1.0 have we? | 13:32.02 |
| Robin_Watts | outlines is probably all. | 13:32.20 |
| tor8 | the t3 stuff should merge easily one would hope | 13:32.41 |
| | one chunk in fitz/res_font.c that deals with type3 fonts and pdf/pdf_type3.c; the device call for rendering it shouldn't be affected by changing to display lists | 13:33.54 |
| Robin_Watts | let me see if I can sort this without resorting to such major type3 changes. | 13:34.52 |
| | those changes may be the right way to go in the long run though. | 13:35.07 |
| tor8 | I doubt you can, the changes shouldn't be too big | 13:35.13 |
| | if you want I can make a patch for type3 while you investigate other options | 13:35.26 |
| Robin_Watts | tor8: go for it. | 13:35.43 |
| kens | Robin_Watts : and/or chrisl could one of you try Gemma'a latest file please ? I reproduced the problem, but when I tried to debug it the problem went away, and now I can't get ti to come back. Can one of you see if you get an error please ? | 13:39.03 |
| chrisl | I'll need to do a build - is this likely to be Windows specific? | 13:43.37 |
| kens | possivbly | 13:43.47 |
| Robin_Watts | tor8: I think you're right. Display lists are the way to go. | 13:43.50 |
| | I think we *can* solve it by passing more fz_context pointers around (because we have a file lock), but it's going to be a LOT more pointers. | 13:44.35 |
| kens | chrisl she gets an 'ioerror' I did gfet an 'undefinedfilename' error, but now I can't reproduce it | 13:45.11 |
| tor8 | Robin_Watts: damn. fz_render_t3_glyph_direct can affect the incoming gstate :( | 13:46.34 |
| | which means we need both approaches... | 13:46.51 |
| chrisl | kens: running on Linux now - building on Windows, too..... | 13:47.06 |
| kens | OK thanks chrisl | 13:47.13 |
| chrisl | Hmm, this ain't a quick file! | 13:47.25 |
| Robin_Watts | tor8: Ass. | 13:47.46 |
| kens | No, its big and failry complex | 13:47.51 |
| | and has three spots | 13:47.58 |
| Robin_Watts | OK. Shall I push through with the fz_context stuff and see what I end up with ? | 13:48.25 |
| tor8 | Robin_Watts: but render_direct is only called from the interpreter, never from the callback | 13:48.30 |
| | so I think we'll be okay anyway | 13:48.39 |
| | render_direct is hacky, but so is the brain dead spec problem it's solving | 13:48.56 |
| chrisl | kens: It's not using a lot of memory (so far), though, which is interesting | 13:49.04 |
| kens | Cna't really comment | 13:49.20 |
| Robin_Watts | tor8: Right. if we find a glyph that inherits the current gstate, we render it direct as a series of graphics operations, not as text. | 13:50.36 |
| | so yes, you're right, we should be fine. | 13:50.49 |
| tor8 | Robin_Watts: yeah. we just have to preserve that and not rip it out as my first thought was. | 13:51.00 |
| | so basically just adding a t3lists array and pre-populate that, and use it in all but the render_direct case | 13:51.27 |
| Robin_Watts | tor8: Ah, we are walking the t3 glyphs that are used anyway, to find the bbox/whether they need direct handling or not. | 13:53.50 |
| | So we 'just' render them to a display list at that point. | 13:54.10 |
| | OK, that seems less painful than I'd feared. | 13:54.19 |
| | kens: I need to rebuild gs. I've set that off, and will look at the results after lunch. | 13:54.58 |
| chrisl | kens: I seem to remember we (I) did a build for Gemma that used the old output file naming - maybe that's the difference? | 13:55.44 |
| kens | chrisl It could be, though why I got an error once escapes me. | 13:56.16 |
| chrisl | It worked fine on Linux, it's running on Windows now | 13:56.40 |
| kens | OK, thanks chrisl, maybe my problem was a fluke | 13:56.54 |
| | chrisl why did you do one with old naming ? I seem to recall there was a reason, was it because they needed that ? | 13:58.01 |
| chrisl | Yes, apparently their "system" couldn't handle the change in the file names | 13:58.31 |
| kens | Yes, thought it was that. | 13:58.47 |
| chrisl | I seem to remember it was a really trivial change, I'm just looking for the e-mail about it | 13:59.30 |
| kens | One of the spot plates has a space in the name, which could be the problem, but I *thought* that worked | 13:59.48 |
| tor8 | Robin_Watts: exactly. | 13:59.55 |
| chrisl | kens: it definitely had worked, I've tested quite few files with Pantone colors, and they always have spaces | 14:01.12 |
| kens | chrisl Robin_Watts don't spend much time on this, if it works OK with current code I'll let Marcos try and bisect it. Either that or Gemma will have to take a release witho our naming in it | 14:01.53 |
| chrisl | kens: it's no problem - the change for the file naming involves changing a "true" to a "false" - I'm waiting on the file completing on Windows with the current code. | 14:03.38 |
| kens | OK. Its possible it something that's been fixed of course | 14:03.59 |
| chrisl | I can't remember there being changes in that area recently.... | 14:05.12 |
| kens | No me neither | 14:05.46 |
| | Like I said, if we can't reproduced a problem I'll leave it to Marcos next week. | 14:06.10 |
| | back in a moment | 14:06.26 |
| tor8 | Robin_Watts: patch on tor/master, needs sane testing | 14:14.57 |
| kens | chrisl did the Windows one finish ? | 14:18.24 |
| | I htink I just found out why my first attempt failed, I had a typo in the command line | 14:19.56 |
| chrisl | kens: yes, the second one just finished - so both naming schemes run to completion on Windows. The only other variable that springs to mind is 32 vs 64 bit - can't imagine that making a difference, thoug | 14:20.23 |
| kens | I tried both | 14:20.33 |
| | OK, so I'll reply to Gemma and tell her we can't see a problem, and that Marcos will look into bisecting it next week | 14:22.12 |
| | chrisl you realise that this, along with their other fix, means you will have to build them a new version again ? | 14:23.23 |
| chrisl | Or we can make them wait until Feb..... | 14:23.45 |
| | I wonder if they are using vFAT or something like that? | 14:23.59 |
| | Oh, amazingly, I still have the binaries I built for them back in September - I'll try it on there | 14:25.25 |
| kens | Wow, that would be ideal | 14:25.42 |
| | I'll stop that email going out | 14:25.58 |
| chrisl | I'm running the 32 bit one now - it will take some time! | 14:26.09 |
| kens | No rush | 14:26.14 |
| chrisl | kens: the 32 bit exe from September ran to completion, I've started teh 64 bit one now, just for completeness | 14:37.12 |
| kens | Interesting, so we cna't reproduce her problem using the same binary | 14:38.11 |
| chrisl | Yeh - I'm using Windows 7, 64 bit - again, I doubt that would make any difference. | 14:38.59 |
| kens | I can't see how | 14:39.17 |
| | chrisl did you get any of the messages in her screenshot ? | 14:40.12 |
| | 'Dropping incorrect smooth shading object' ? | 14:40.26 |
| chrisl | Nope, none of those, just the "SeparationName:" ones | 14:40.44 |
| kens | I wonder if she sent a 'modified' version of the file then | 14:40.59 |
| | Maybe Acrobat fixed it. | 14:41.06 |
| chrisl | Evince doesn't report any problems. | 14:42.04 |
| kens | Yeah, I wonder if this is the right PDF file | 14:42.18 |
| | OK I will reply to Gemma now | 14:44.23 |
| chrisl | Well, I get an extra spot plate compared to Gemma's output (there's a Diecut plate in this file) - it does *seem* like a different file | 14:44.41 |
| kens | Indeed. I noticed the exstra plate, but I thought it just might not have got that far before erroing out | 14:45.12 |
| chrisl | I *think* we print the spot plate names *before* we start to generate output, so I would expect all the plate names to be emitted before the error | 14:46.24 |
| kens | chrisl I just read the screenshot | 14:47.39 |
| | THe file there is called 'crisps.pdf' | 14:47.46 |
| | SO I think she's sent the wrong file (again) | 14:48.01 |
| Robin_Watts | Runs without error for me. | 14:48.12 |
| | kens: feel free to point out to her that each time she sends the wrong file it costs hours of our time. | 14:48.28 |
| chrisl | Could be - the file she sent is an advert for crisps, though | 14:48.29 |
| kens | chrisl I know, but.... | 14:48.40 |
| | Robin_Watts : I will try to put that politely | 14:48.47 |
| chrisl | it doesn't instill confidence | 14:48.55 |
| Robin_Watts | Aren't they on a limited hour support contract ? | 14:49.04 |
| kens | Robin_Watts : yes, but.... | 14:49.10 |
| ela_ | Does anyone know under what conditions the DCTDecode filter raises a rangecheck error (parameter dictionary provided)? | 15:38.47 |
| kens | when an entry is our of range | 15:39.13 |
| | out* | 15:39.18 |
| ela_ | entries are from the JPEGTables field of a TIFF image. | 15:40.13 |
| kens | Most of the dictioanry entries are quite different to those. | 15:40.40 |
| | All I can tell you is something is wrong, unless you post an example | 15:41.02 |
| ela_ | sorry, /QuantTables has only one string. | 15:43.53 |
| | any clues? | 15:46.00 |
| kens2 | ela_ : No not really, a value is out of range, that's all I can say | 15:52.40 |
| ela_ | Is there any chance to get more detailed error information? | 15:54.40 |
| kens2 | ela no not really. Post an example and we cna debug it, without that there are too amny possibilities | 15:58.34 |
| | Forward 1 day (to 2012/11/24)>>> | |
IRC Logs