| | <<<Back 1 day (to 2011/09/15) | 2011/09/16 |
| Robin_Watts | An Icelandic concert? | 00:00.32 |
| sebras | Robin_Watts: yup. I attended an concert in Copenhagen by FM Belfast. Happy, but exhausted. :) | 00:01.15 |
| | Robin_Watts: my colleagues over at my, soon to be former, workplace favour global variables so I will not say too much abou fz_context I believe. | 00:02.45 |
| Robin_Watts | sebras: We specifically want thread safety - hence need to remove global vars. | 00:03.16 |
| sebras | Robin_Watts: makes sense. | 00:03.35 |
| | Robin_Watts: need to go to bed. good night! | 00:04.22 |
| Robin_Watts | likewise. night. | 00:04.33 |
| tor8 | Robin_Watts: int and string is fine, so is just int (and simply print the message to stderr when thrown) | 00:52.25 |
| kens | Hmm, floor seems to be broken in MSVC.... | 09:42.36 |
| | floor(0.0078125) = 1016 | 09:42.53 |
| chrisl_x100 | I've found some library functions return nonsense values if you evaluate them in the debugger. | 09:45.57 |
| kens | I'm looking at the variable containing the result | 09:46.15 |
| | I'd like to think that's right.... | 09:46.24 |
| | Hmm, maybe I'm not invluding math.h | 09:46.46 |
| chrisl_x100 | Could be...... | 09:47.18 |
| kens | Seems its not there in the source module | 09:47.36 |
| | Ttring again with it included | 09:47.43 |
| | Phew, that works.... | 09:48.10 |
| | The output file seems to be still broken though | 09:52.38 |
| enricostn | hi to all | 11:52.41 |
| | I've a problem using gs on archlinux | 11:53.08 |
| | https://bbs.archlinux.org/viewtopic.php?id=126578 | 11:53.26 |
| | could anyone help me please? | 11:53.36 |
| | it's a path related problem I think, but I can't understand how to fix it | 11:54.22 |
| kens | Usually that means you mistype '-sOutputFile', but it might also mean the file cannot be opened | 11:54.28 |
| | Try giving a complete path to OutputFile | 11:54.41 |
| enricostn | what if the output file doesn't exist? | 11:54.52 |
| kens | It will be created | 11:55.00 |
| | assuming permissions are OK | 11:55.13 |
| | At the very least you should use ./output.pdf | 11:55.33 |
| enricostn | giving a path like "/filename.pdf" doesn't help | 11:55.35 |
| kens | Does the path exist ? Is it a fully qualified path ? Are the permissions set to allow file creation and writing ? | 11:56.18 |
| Robin_Watts | enricostn: Try working up to it in bits. | 11:56.20 |
| | gs input.pdf | 11:56.30 |
| kens | What version of Ghostscript are you using ? | 11:56.30 |
| enricostn | gs 9.04 | 11:56.42 |
| Robin_Watts | then: gs -sDEVICE=pdfwrite -o output.pdf input.pdf | 11:56.46 |
| kens | As Robin says | 11:56.50 |
| enricostn | path is my home | 11:56.51 |
| | like /home/enrico | 11:57.02 |
| kens | Try also using a rendering device such as png, and see if aht acan write an output file. | 11:57.24 |
| enricostn | the syntax is -sOutputFile or sOutputFile ? | 11:58.09 |
| kens | -s | 11:58.17 |
| enricostn | ok thank you a lot, was a syntax problem... | 11:59.39 |
| | and now I know how to reduce PDF file size easily (2.5MB to 150KB...) | 12:00.38 |
| | thank you again | 12:00.57 |
| kens | with loss of quality though | 12:01.01 |
| enricostn | yes but in my case it's not important | 12:01.18 |
| kens | Yep, usage is the key. | 12:01.28 |
| | for screens, its probably fine. | 12:01.37 |
| enricostn | almost text | 12:01.42 |
| kens | Hmm, surprised it makes a difference then. Usually that comes form reducing the size of images | 12:02.00 |
| | Still, as long as its good for your purposes, tehn its fine | 12:02.19 |
| enricostn | yes, is a document produced in word for Mac with some design, little logos etc | 12:04.49 |
| | generally bigger than required | 12:05.24 |
| kens | Hmm, a recognisable (if rather thin) capital M, success! | 13:28.55 |
| cipri | hi. any MuPDF guys here? | 13:29.10 |
| kens | Yes. | 13:29.17 |
| cipri | i have a question. Do you you plan in future to support djvu files too? (and not only pdf and xps= | 13:29.46 |
| kens | I would very much doubt it. | 13:29.57 |
| cipri | why not? I dont much abut djvu internal structure, but I think it could be similar to pdf/xps | 13:30.44 |
| kens | Its not a specified document standard for starters. | 13:31.06 |
| cipri | or is djvu not popular enough for supporting it? | 13:31.08 |
| | aaa | 13:31.11 |
| | and something else. Do you intend to make mupdf thread safe? (at the moment one needs to do extrac mutex locking/unlocking) | 13:33.46 |
| kens | Yes, the intention is to improve it to be thread safe at some point. | 13:34.03 |
| | But I'm not the expert on that. | 13:34.19 |
| Robin_Watts | cipri: Yes, we're working on that. | 13:34.25 |
| | djvu *is* an open, specified file format it seems. | 13:34.44 |
| kens | But not a document standard ;-) | 13:34.54 |
| | There are *many* documented file formats, I really don't think we want to get into supporting them. | 13:35.12 |
| cipri | i was reading somwhere that some functions of libdjvu are leaking memory, that's why I would be interested into an alternative to it. | 13:36.37 |
| kens | Wouldn't it be better to get libdjvu fixed ? | 13:36.56 |
| | Now that PDF supports JBIG2 and JPEG2000 I wonder if DjVu is still smaller, really. | 13:37.48 |
| cipri | well. If the guys who are developing libdjvu didnt fix that, than of course I would like to avoid it, since I guess it's not something easy to fix, otherwise it would have already happened. | 13:38.54 |
| | yes, indeed, I noticed that more recent pdf files are getting more close to the size of djvu | 13:39.40 |
| chrisl | I suspect that's more a case of libdju getting very little attention - DjVu isn't exactly a popular format these days. | 13:40.03 |
| cipri | but there are still a lot of books in djvu format, and i want my viewer to support it o | 13:40.05 |
| | too* | 13:40.17 |
| Robin_Watts | From my limited (30 seconds) googling it sounds like djvu doesn't use any technology that isn't there in pdf. | 13:41.06 |
| | So it's probably possible to convert from djvu to pdf without reencoding everything. | 13:41.22 |
| cipri | yes, i guess it works, but from my experience (as a user) scanned files in djvu format are more lightweight. | 13:45.02 |
| kens | I don't see any gain for us i supporting the format, | 13:45.34 |
| | Its seems obscelescent now | 13:45.41 |
| cipri | here is a little comparision/information related to pdf vs djvu http://djvu.org/resources/djvu_digital_vs_super_hero_pdf.php | 13:48.01 |
| Robin_Watts | Certainly, I don't see it as a priority :) | 13:48.01 |
| chrisl | cipri: if you feel very strongly about it, mupdf is available under GPL...... | 13:48.58 |
| cipri | of course :P, I just wanted to see your opinion, I dont ask you to support it | 13:49.29 |
| chrisl | Or bang on the libdju people to fix their bugs ;-) | 13:51.13 |
| cipri | another question: Is it possible to add annnotations to a pdf file using libmupdf? (I read that it displays annotations, but I'm curious if I also can create annotations) | 13:54.13 |
| Robin_Watts | cipri: not currently. | 13:54.24 |
| | but given mupdf can 'clean' pdfs and reoutput them (to repair broken ones etc), it may not be that hard to add. | 13:55.17 |
| cipri | Robin_Watts: and when do you expect it could get that feature? | 13:55.23 |
| Robin_Watts | It's not on our immediate roadmap. | 13:55.38 |
| cipri | and now a subjective question :-) : What Viewer/PDFViewer do you think has the best User Interface (and features)? | 13:58.29 |
| kens | Acrobat pro has more features than any other 3 put together. | 14:00.01 |
| | Bu thte UI isn't great and they keep on changing it. | 14:00.12 |
| Robin_Watts | and it keeps corrupting itself, IME. | 14:00.31 |
| kens | Not a problem I've experienced | 14:01.00 |
| Robin_Watts | Maybe I've just been unlucky. | 14:01.22 |
| | 100dpi, banded, pdf_reference17.pdf: plank=115s, pamcmyk4=131s. | 14:02.48 |
| cipri | so, then, which viewer do you think has the best UI. I'm interested, because I'm searching for inspiration :P. I did already already a basic pdf-viewer, and I want to improve the UI. You can see it here | 14:03.09 |
| | http://haikuware.com/remository/view-details/development/app-installation/augur-pdf-viewer-demozip#comment-8269 | 14:03.11 |
| Robin_Watts | cipri: Depends on the device. | 14:03.31 |
| | And the input method. | 14:03.45 |
| | Picsels stuff is very good for mobiles. | 14:04.05 |
| cipri | for the normal pc at the moment (keyboard and mouse) | 14:04.07 |
| henrys | Robin_Watts:if the color model were kcmy would it be easy to add a state variable that said k was black and take appropriate action next planes? | 14:07.10 |
| tor8 | cipri: djvu has a patent on it that can't be worked around | 14:07.34 |
| | that's why it's not very popular | 14:07.45 |
| Robin_Watts | henrys: Sorry? | 14:07.54 |
| henrys | Robin_Watts:then you have problems going the other way. | 14:08.03 |
| | I am trying to think how you can treat 0001 as 111 without reading all the planes. | 14:08.27 |
| Robin_Watts | henrys: In an ideal world, I'd like to be able to process all the c plane, then all the m plane, then all the y plane, etc. | 14:08.53 |
| | So a single state variable isn't going to help. | 14:09.05 |
| | would need one per pixel. | 14:09.11 |
| | which means we're effectively treating planes together. | 14:09.25 |
| | Did you see my mail from last night? | 14:09.39 |
| henrys | or one per rectangle | 14:09.46 |
| Robin_Watts | That only works if we have a solid color fill. | 14:10.10 |
| henrys | Robin_Watts:right | 14:10.17 |
| Robin_Watts | If we have a halftone fill, then we're still slow. | 14:10.24 |
| henrys | Robin_Watts:yes I did read it. | 14:10.26 |
| Robin_Watts | I think I like the idea of having a 'regenerate k plane' flag in the device. | 14:10.53 |
| | Then whenever we need to do a rop, we do it just in the cmy planes (all by themselves), and set that bit. | 14:11.18 |
| | At output time, we then regenerate k from cmyk. | 14:11.30 |
| | So we get proper color management everywhere unless rops are used. | 14:11.48 |
| | rops will be fast (no planar to chunky and back, cmyk->rgb and back conversion) | 14:13.43 |
| | And we can even have it as an option, so people can choose fast rops or color correctness. | 14:14.07 |
| henrys | yes definitely a correctness option. | 14:16.59 |
| | are you suggesting changing the color model on the fly? I think that will take a lot of work in the code. | 14:18.00 |
| Robin_Watts | No, not at all. | 14:18.09 |
| | When we do a rop, we ask the device 'do you support fast cmyk rops?' | 14:18.28 |
| henrys | note reading all the planes is not that painful they are reduced to 1 bit each right? | 14:18.42 |
| Robin_Watts | If the device says yes, then we go to some special code that 'inverts' the rop (so it works on cmy, not rgb) and we run that rop on the cmyk data. | 14:19.36 |
| | The device notes when such special code is used. | 14:20.14 |
| | and then when the device goes to output a page, if the special code has been used, it ignores the k plane, and regenerates it from the cmy. | 14:20.43 |
| henrys | oh yes there is no issue if the output device is rgb as you have in your mail - I thought you were still in cmyk, that is where things are more difficult. | 14:21.07 |
| Robin_Watts | I was intending to be in cmyk. | 14:21.27 |
| henrys | okay so text for example is color managed so black goes to just k not 111 cmy - so when you go to rops the profile changes the color caches have to be dumped there are special things in the halftoning - I think a new halftone is neeeded, on and one. | 14:24.27 |
| | I am not saying it can't be done I suspect a lot of code has to change. | 14:25.06 |
| Robin_Watts | If we use the 'fast cmyk rops' option and a file uses rops, then effectively the k plane would be ignored, and k would be generated just from the cmy. | 14:25.44 |
| | If that's not acceptable, then this idea won't fly. | 14:26.00 |
| | Let's step back from this for a moment. | 14:27.46 |
| | You sais last night that the PCL manual claims that rops are actually done in cmyk ? | 14:28.06 |
| henrys | no the manual claims they are done in cmy. | 14:28.33 |
| Robin_Watts | Ah, ok. | 14:29.00 |
| | This is for 1bit per component cmy or for nbit ? | 14:29.39 |
| henrys | what I don't know (a question for michael) is can we do a low end business graphics printer without k - obviously 111 must map to the black toner cartridge but given that is it possible. If so there is no issue really. | 14:30.41 |
| Robin_Watts | Can we work a couple of examples? I have some worries. | 14:31.05 |
| | White is represented as 0000. Suppose I have an 'invert' rop. | 14:31.26 |
| | Doing it via RGB, that would convert to rgb = 111, then invert to get rgb = 000, then convert to cmyk to get 0001 ? | 14:32.08 |
| henrys | I think that depends - typically text is treated that way images might end up with 1110 | 14:33.05 |
| Robin_Watts | I think all our 1bit mapping code will ensure we get 0001. | 14:34.08 |
| | For n bits, it's a different matter. | 14:34.31 |
| henrys | I thought michael just made that an option but maybe I didn't understand something. | 14:34.57 |
| | anyway what you said is right. | 14:37.17 |
| Robin_Watts | OK, second example: reverse the one I just did. | 14:38.13 |
| | 0001 should invert to give 0000, right? | 14:38.36 |
| henrys | yes | 14:38.50 |
| Robin_Watts | Neither of those works right if you consider just the cmy. | 14:39.23 |
| | because of the awkward black case. | 14:39.47 |
| henrys | I am saying the color model would be cmy throughout and 111 would be black. | 14:40.01 |
| Robin_Watts | (i.e. we can't use cmyk and just ignore the k) | 14:40.03 |
| | right. | 14:40.05 |
| henrys | we actually have a cmy device in cups I don't know how well it works. | 14:40.32 |
| Robin_Watts | Maybe the right thing to do is to make a new planX device. | 14:40.54 |
| | "plancmy" or something. | 14:41.13 |
| henrys | I think that is what's needed and what I dread is a shared language implementation - because we'll have to switch back to cmyk for ps and pdf. | 14:41.53 |
| Robin_Watts | Actually, I could just stick to using "planrgb" and invert the bits on output. | 14:42.52 |
| | henrys: Do we have to have one consistent device across all languages ? | 14:43.11 |
| | Can we not use plank for ps and pdf, and use plancmy for pcl ? | 14:43.31 |
| henrys | no we just have to make sure we do stuff like have a large enough framebuffer all the time. | 14:44.07 |
| Robin_Watts | what question was that no to? (sorry) | 14:44.36 |
| henrys | no the device does not need to be consistent. | 14:45.44 |
| Robin_Watts | right. | 14:45.49 |
| | So, let me try knocking up a "planr" device (a 1bit per component plan cmy device) that really works in rgb space, and just inverts the bits on output. | 14:46.51 |
| | and generates a k from that. | 14:47.05 |
| henrys | but I'm not sure we are always goint to resize things appropriately - there may be a few bugs we have to track down as a consequence of changing the device. | 14:47.06 |
| Robin_Watts | Are you thinking in terms of a language switch build ? | 14:47.32 |
| henrys | yes | 14:47.39 |
| | but for the immediate future we just need to worry about pcl. | 14:47.55 |
| Robin_Watts | Hmm. | 14:48.13 |
| henrys | at least for company 'R''s performance results. | 14:48.21 |
| Robin_Watts | Just thinking here... | 14:48.41 |
| | if we generate rgb 1 bit output, then post process that to get cmyk out of it... why does the rgb need to be planar at all? | 14:49.13 |
| chrisl | Robin_Watts, henrys: could you not have a CMYK device, then have PCL push a CMY ICC profile into it, and have the ROP code ignore the K channel? | 14:49.54 |
| henrys | I thought we needed planar for fast halftoning - it should be faster to halftone a plane at a time. | 14:51.08 |
| Robin_Watts | Oh, right, maybe, yes. | 14:51.19 |
| henrys | chrisl:yes that might make more sense than switching the device but I suspect there are many areas in the code that really expect the four bits. I may be wrong about that with michael's icc changes. | 14:53.09 |
| Robin_Watts | chrisl: If I understand what you're saying, that would result in nothing ever using the K channel? | 14:53.50 |
| chrisl | Robin_Watts: PDF/PS would use a CMYK profile | 14:54.15 |
| Robin_Watts | right, but in pcl, nothing would ever use the k channel ? | 14:54.27 |
| chrisl | That's right, you'd have to post-process to get the K channel | 14:54.47 |
| Robin_Watts | Right. | 14:54.51 |
| chrisl | henrys: just thinking out loud, after you mentioned the cups device which accidentally tried to do something similar. | 14:55.19 |
| Robin_Watts | But then, if we're doing that, we might as well just run in rgb anyway, so we only have to maintain 3 planes throughout, and not have to change the hairy rop/getbits code. | 14:55.41 |
| | If people want color management with pcl, they could provide an rgb -> cmyk profile to use at the end maybe ? | 14:56.33 |
| henrys | you can't it's already halftoned at the end. | 14:57.09 |
| Robin_Watts | (planar to planar via a color profile could be... interesting) | 14:57.14 |
| | I was thinking for non halftoned cmyk (planc, rather than plank) | 14:57.31 |
| henrys | we'll never meet the performance requirement pushing contone through the pipeline. | 14:58.17 |
| | I do think we need mvrhel2's input on this. | 14:59.44 |
| | he may veto all of our ideas ;-) | 14:59.59 |
| Robin_Watts | Then that just gives me today to get planr working :) | 15:00.22 |
| henrys | working is good | 15:01.18 |
| | chrisl suggestion doesn't require any changes to the device, I'm just not sure what else needs to change to support it. | 15:09.21 |
| Robin_Watts | chrisl's suggestion does require hairy changes to the insides of getbits and the rop code, right ? | 15:11.17 |
| henrys | just the rop code I believe. | 15:15.26 |
| | you do the cmyk getbits as usual and ignore k | 15:16.02 |
| Robin_Watts | It changes the getbits operations that the rop code needs to do; if we are doing a rop on a cmyk device (and fast rops are enabled) then we'd need to do the getbits in cmyk rather than rgb. | 15:22.12 |
| | So that changes the path through the getbits code; we might start to miss all the optimised routes. | 15:22.29 |
| henrys | well let's plan a meeting monday with michael. | 15:28.31 |
| | are there any performance issues sans rops? | 15:29.14 |
| Robin_Watts | I haven't seen figures from marcos yet. | 15:29.30 |
| | but pdf_reference17.pdf runs faster as planar than chunky. | 15:29.40 |
| | (at 100dpi, banding) | 15:29.54 |
| | 115 vs 131 seconds on my machine. | 15:30.09 |
| | And that's without the fast halftoning stuff. | 15:30.19 |
| henrys | right I saw that looks encouraging. | 15:30.25 |
| Robin_Watts | Hmm. I have planr building, but when I try to use it I get: **** Unable to open the initial device, quitting. | 15:41.20 |
| | And plan_open isn't being called... | 15:41.34 |
| | oh, stupid type. | 15:44.51 |
| | typo. | 15:44.53 |
| | Do we have any other 1bit rgb devices ? | 15:53.06 |
| henrys | yes bitrgb | 15:56.22 |
| Robin_Watts | Ah, the planar device dislikes being asked for a depth that isn't an integer multiple of the number of components. | 16:06.46 |
| | oh, what a fool. | 16:28.45 |
| | The device is fine, it's my output code that's knackered :( | 16:28.56 |
| | Right, we have a cmy planar device. | 16:32.48 |
| | This may be a question for mvrhel2, but when halftoning, do people typically use different sized tiles for each plane ? | 16:37.57 |
| | (sizes that aren't simple multiples) | 16:38.16 |
| henrys | not sure about that. | 16:41.02 |
| Robin_Watts | If the sizes are all the same, then why is thresholding easier for planar? | 16:41.21 |
| kens | sizes are not normally the same, because angles vary | 16:41.43 |
| Robin_Watts | If the sizes *aren't* the same, then surely you can end up with unexpected cmyk levels. | 16:42.06 |
| kens | they can be though, jut less accurate angles that way | 16:42.08 |
| Robin_Watts | (i.e. you might end up with both C and K, where usually you'd expect K to 'knockout' the C) | 16:42.52 |
| kens | I am not an expert ;-) | 16:43.03 |
| Robin_Watts | me either, as I believe my questions are admirably demonstrating :) | 16:43.28 |
| | lj5200_pcl6_mono_PWTW51DC.prn: 600 dpi, banded: pamcmyk4=21s, plank= 47s, planr=74s | 16:46.01 |
| | That's *not* what I expected. | 16:46.11 |
| kens | Night all. | 16:55.22 |
| henrys | I thought memory access was much faster with planar halftoning (no screen switching) and you should be able to set say a byte at a time or more in the output without scattering bits right? | 17:10.47 |
| | other than that because peter says so:http://www.ghostscript.com/pipermail/gs-devel/2001-October/004545.html ;-) | 17:12.12 |
| Robin_Watts | If the halftones are the same size, then you just bake one chunky halftone threshold array and use that. | 17:14.56 |
| | so no screen switching. | 17:15.02 |
| henrys | guess I'd have to think about that - there are 4 independent screens on a cmyk device. I don't see how that could be reduced to one threshold array. | 17:25.32 |
| | but michael has a lot more depth than I do about this. | 17:26.55 |
| Robin_Watts | if the halftone tiles are all the same size, then we can simply bake all 4 into 1 chunky version. | 17:28.57 |
| | But that's a big if - hence my initial question. | 17:29.13 |
| | OK, so 98% of CPU time in the planr device is in malloc. | 17:29.49 |
| henrys | how? they have different threshold values say position 0,0 in the C dither many be a different value than M at the same position.. | 17:31.28 |
| | s/many/may | 17:31.38 |
| Robin_Watts | Suppose we have a 2x2 tile size, for simplicity. | 17:31.58 |
| | where the C tile is a b c d, the M tile is e f g h, the Y tile is i j k l, and the K tile is m n o p | 17:33.04 |
| | We can bake that into a 8x2 tile: a e i m b f j n c g k o d g k p | 17:33.42 |
| henrys | is this the dither matrix you are talking about? | 17:33.43 |
| Robin_Watts | No, I was thinking of a threshold array, but aren't the two isomorphic ? | 17:34.32 |
| henrys | I see what you are saying yes I thought you meant you could fit that information in an object of the original tile size. | 17:34.33 |
| Robin_Watts | No, not at all. | 17:34.43 |
| | I must check the code my dog wrote... | 17:35.16 |
| | Right, that's limited to 1 component only at the moment. | 17:37.46 |
| | planr is still going through a planar_to_chunky stage; seems rops can't be done on planar data directly at the moment. | 17:51.43 |
| | I've just updated the planar rop code so it can do the rops staying in planar space when it doesn't involve being passed source or texture bitmap/pixmap data. | 18:55.54 |
| | (i.e. if the Source is unused, or the Source is a constant color). | 18:56.21 |
| | If the source (or texture) is a bitmap, then I can't stay in planar space as I'd need to unpick the source into planes. | 18:56.46 |
| | unpicking the source may be an option actually; that'd be chunky_to_planar, and would save me doing a planar to chunky then a chunky_to_planar later on. | 18:58.00 |
| | Doesn't seem to save me any time on the file I was testing though. | 18:58.41 |
| | This file seems to be ropping a monochrome image onto the screeen. Not sure michaels code copes with mono data -> color screen yet. | 19:00.07 |
| | And i'm sure it doesn't cope with mono data ropped onto a color screen. | 19:00.27 |
| henrys | I have to leave for lunch pretty soon. I'll read up when I return. | 19:00.52 |
| Robin_Watts | I'm baling soon. I think we've done enough to consult with michael. | 19:02.24 |
| Lafriks | hi | 23:18.06 |
| ghostbot | hey | 23:18.06 |
| Lafriks | Is there anyone from mupdf developers? | 23:18.41 |
| Robin_Watts | yup. | 23:18.51 |
| Lafriks | I have been fighting for last few days on making mupdf thread safe and finally have succeeded... | 23:19.43 |
| Robin_Watts | Ah. We're doing the same here. | 23:19.58 |
| Lafriks | I wanted to ask is there are intrest from pushing it upstream | 23:20.09 |
| Robin_Watts | Certainly send in your patch. | 23:20.23 |
| Lafriks | its huge :P | 23:20.32 |
| Robin_Watts | I suspect that our method will be different to yours though. | 23:20.33 |
| | We are pushing a 'context' through the code, and the various globals are going into that. | 23:20.52 |
| Lafriks | my method in short is to have fz_state struct (or call it context) that contains ex-static variables to push around | 23:21.33 |
| Robin_Watts | Sounds similar. | 23:22.26 |
| Lafriks | anyway if there is such interest I can clean it up on monday and send it in | 23:22.41 |
| Robin_Watts | You can see the work in progress for ours: http://git.ghostscript.com/?p=user/robin/mupdf.git/.git;a=shortlog;h=refs/heads/failing_allocs | 23:23.14 |
| | The context is also used to allow us to do exception throwing, which we intend to start to use. | 23:24.06 |
| Lafriks | at least it is working just fine in threaded enviromet (I'm using it from C# using swig generated layer) | 23:24.08 |
| Robin_Watts | Lafriks: seeing your code would be good as an indicator of all the globals we need to capture :) | 23:24.41 |
| Lafriks | is your code is in working condition already? | 23:26.15 |
| Robin_Watts | The branch in git builds and seems to work. | 23:26.37 |
| | It's not fully tested. | 23:26.42 |
| | The globals haven't all been pulled into the context yet, but hopefully the context should be available in most of the places where it's needed. | 23:27.16 |
| | It's a first step along a long road. | 23:27.31 |
| Lafriks | as much as I did a quick look at your code our methods is quite similar | 23:31.57 |
| | but I did change the api a bit less | 23:32.22 |
| | I mostly changed just methods that initialize structs and saved pointer to 'context' in theses structs for reusing in other methods | 23:34.13 |
| | I also did leave the old error handling method so I had to add context parameter to all fz_throw, fz_rethrow etc methods | 23:36.55 |
| | Robin_Watts: but fz_try fz_catch seems quite nice :) | 23:39.11 |
| | should have asked in irc before starting on doing it myself... would have saved me quite a lot of compiling error fixing after I deleted static variables :D | 23:41.14 |
| | There is one thing what I really wanted to ask you | 23:45.41 |
| | about fz_set_aa_level | 23:45.46 |
| Robin_Watts | ok. | 23:45.51 |
| Lafriks | we are using mupdf to generate a lot of images in many threads | 23:46.39 |
| | and we are using multiple alphabits in diferent threads | 23:47.10 |
| | I haven't yet tested that fully and I don't know all what happens inside when drawing happens but to me it seems that they will mixup | 23:48.19 |
| | ? | 23:48.30 |
| Robin_Watts | You're using different alpha settings in different threads? | 23:48.43 |
| Lafriks | yes | 23:49.01 |
| | there are multiple threads that genereate different resolution images | 23:49.27 |
| Robin_Watts | OK, so I'm assuming you're building with AA_BITS undefined ? | 23:49.56 |
| | If you do that, you can call fz_set_aa_level to set the number of bits to use. | 23:50.28 |
| | That sets various fz_aa_ static variables. | 23:50.42 |
| | If you've moved those into your thread specific context, you should be OK. | 23:50.54 |
| | If you've left them as statics you'll have problems. | 23:51.08 |
| Lafriks | yes, I'm using AA_BITS undefined | 23:52.31 |
| | that's what I wanted to know | 23:52.49 |
| | so I'll have to move these one also into context than | 23:53.17 |
| Robin_Watts | yes. | 23:53.28 |
| Lafriks | one more thing if you are not too busy ;) | 23:55.15 |
| | there are some places where static methods are used | 23:56.00 |
| | what is the reason for that? | 23:56.43 |
| Robin_Watts | Ah, you mean static function pointers? | 23:57.01 |
| | Tor did that to avoid tools bloating. | 23:57.41 |
| | Currently, the pdfclean executable for example is very small. If he'd called direct, it would have linked in lots more stuff and so would have caused all the fonts and things to be included to. | 23:58.32 |
| | too. | 23:58.35 |
| Lafriks | oh, ok | 23:59.09 |
| | Forward 1 day (to 2011/09/17)>>> | |
IRC Logs