| | <<<Back 1 day (to 2018/03/11) | 20180312 |
| kens | Hmm, well that's interesting. If I render the PDF file resulting from bug #699102 with Ghostscript, I get the same answer as rendering the original PCL file with GhostPCL. If, however, I open the PDF file in Acrobat, the display is different. | 11:34.55 |
| | MuPDF matches Ghostscript | 11:37.31 |
| | Opening the PDF in Firefox is the same as Ghostscript and MuPDF | 11:39.33 |
| | The windows download for it doesn't seem to work :-( | 11:41.36 |
| | OK fosshub seems to have a copy, god knows how old | 11:42.23 |
| | And Evince renders the same as GS et al. | 11:45.39 |
| | The odd man out is Acrobat, so I think this can be classed as a bug in Acrobat. | 11:45.51 |
| | Oh my.... | 12:05.16 |
| | The problem is that we have an Encoding with a glyph named /.notdef (not this glyph is *NOT* encoded at character code 0). Acrobat is seeing the /.notdef glyph name, and directly pulling the wrong character from the font. It appears to be pulling the character encoded at position 0 | 12:06.34 |
| | velix, no you can't prevent the pdfwrite writing XMP metadata, at least not without modifying the source code. | 12:18.36 |
| | Ghostscript does not 'merge' PDF files, please read https://www.ghostscript.com/doc/9.22/VectorDevices.htm#Overview for an explanation of how the pdfwrite device works. It is unlikely that the low level content of the output PDF file will match in any respect whatever, the low level content of the input PDF file. However, the rsult should be visually the same. | 12:20.07 |
| | Note that a rectangle *is* a path, its just a compact way of representing the path. | 12:20.40 |
| chrisl | kens: Generally Acrobat's special handling of /.notdef is to forcibly make it non-marking for non-symbolic fonts, or allow it to mark for symbolic fonts - but clearly, special stuff has precendent :-( | 12:31.28 |
| HenryStiles | kens: hmm didn't I look at these regressions last release, the asian characters are very familiar? | 12:31.46 |
| kens | Oops, went to lunch | 12:46.48 |
| | HenryStiles : I'm not bothered by the asian characters, just the missing text, I believe its OK but want to check | 12:47.09 |
| HenryStiles | I'm just surprised to see them again. | 12:47.34 |
| kens | chrisl yeah it *really* shouldn't be doing what its doing. If the glyph name i s/.notdef it shoudl use the glyph, and it clearly doesn't. | 12:47.46 |
| | HenryStiles : You mean the ones where the rectangle flips right/left ? | 12:48.01 |
| | The stroke weights are clearly a progression | 12:48.16 |
| HenryStiles | kens: yeah we had a different problem with those same characters last release, not important | 12:50.44 |
| kens | I can't recall what htat was | 12:51.10 |
| | brb | 12:51.33 |
| HenryStiles | paulgardiner: hope you are doing okay | 13:42.23 |
| | kens, chrisl looks like there are a few regressions here, sigh. | 13:58.32 |
| kens | Oh, that's unfortunate | 13:58.42 |
| | Which ones do you think need investigating ? | 13:58.50 |
| HenryStiles | 614 can't be right | 14:01.54 |
| kens | Let me look at that | 14:02.04 |
| | Hmm, I thought it was just text in 'no colour' now being drawn properly | 14:02.46 |
| | I haven't looked at the rendering in PCL though | 14:03.00 |
| HenryStiles | 372 and 384 pdfwrite changed and the raster did not? | 14:03.15 |
| kens | These are 'culled' bitmaps | 14:03.29 |
| | The comparison stops with the first device which shows a difference | 14:03.44 |
| | SO its possible you would get a diff on all devices, but it only gets displayed on the first one | 14:04.00 |
| | Or such is my understanding at least | 14:04.15 |
| HenryStiles | ugh I see doing that for raster but not for pdfwrite | 14:04.20 |
| kens | You'd have to check with Robin_Watts for more details | 14:04.36 |
| HenryStiles | I assumed absence of a raster format indicated a pdfwrite bug, so let me check those also. | 14:05.49 |
| kens | FWIW the pdfwrite output in 614 seems to match the PCL rendering of the original | 14:05.58 |
| | The white text in the reference has gone, I don't think it should have been there, so I think this is a progression | 14:06.35 |
| HenryStiles | okay yup progression, nice | 14:07.07 |
| kens | There's a lot of them, pdfwrite wasn't expecting to get a 'none' colour (I can't remember the PCL term) and so just used whatever was last set, leading to erroneous text | 14:07.55 |
| HenryStiles | seems odd that text missing is a progression, how did you determine that, should I look at those i.e. 560 | 14:09.47 |
| kens | I compared the rendered output of gpcl6 with the display of the PDF file in Acrobat | 14:10.18 |
| | And of course, the reference in the dashboard | 14:10.40 |
| HenryStiles | okay good for me! | 14:11.03 |
| kens | The refrerence in the dashboard had white text drawn over the gray text, the rendered output from the PCL interpreter doesn't and nor (now) does the PDF file | 14:11.13 |
| HenryStiles | so I think the only thing I'm not sure about is 372 and and 384 | 14:11.50 |
| kens | I do believe that a lot of the text differences are down to this long-standing problem. I thin kthe colour index is something like gx_no_color ? | 14:11.55 |
| | Let me look at those | 14:12.01 |
| | 372 is a puzzle, I'm not sure what the right answer should be. I can't say for sure that either is 'wrong' | 14:12.36 |
| | Same with 384, though the broken tail on the fi ligature worries me somewhat | 14:12.59 |
| HenryStiles | kens: so you feel confident I don't need to go through all the diffs? I will if there is any doubt, I only looked at your email. | 14:29.51 |
| kens | The only ones I had any concern with are the ones in the email | 14:30.06 |
| | Are you OK with number 48 ? | 14:30.49 |
| | That's not a pdfwrite one | 14:30.53 |
| HenryStiles | yup that was a fix | 14:32.19 |
| kens | OK just quickly running thorgh these again | 14:32.29 |
| | 662 looked to me and chris like a progression | 14:32.46 |
| | Don't knwo why, but it looks better | 14:32.53 |
| | All the other ones were missing text I think, and I beleive those are all progressions | 14:33.15 |
| | So if you're happy HenryStiles then I'm fine with the PCL diffs | 14:33.50 |
| HenryStiles | ship it :-) | 14:34.49 |
| kens | Nah | 14:34.55 |
| | Need to do another test | 14:35.00 |
| | Robin_Watts : fixed a regression | 14:35.06 |
| | I'm ambivalent about including the potential fix if Michael gives me a way to detect an inappropriate ICC profile for inclusion by pdfwrite too | 14:35.53 |
| | I'm inclined not to, but I think its pretty low risk, and if we're doing another test anyway.... | 14:36.10 |
| HenryStiles | have to say the football game was a highlight of my vacation, the spurs lost but still, what an experience, I've never been. I've never seen so many drunk people in one place | 14:36.30 |
| chrisl | HenryStiles: FWIW, it's just Spurs, not "the Spurs"..... | 14:37.30 |
| kens | But Arsenal, on the other hand, are 'the' gunners | 14:38.06 |
| | Ther's no logic :-) | 14:38.14 |
| HenryStiles | chrisl: oh okay | 14:38.58 |
| chrisl | I wasn't criticising.... it's not like I actually understand football in the slightest! | 14:39.07 |
| kens | chrisl I don' tknow if you want to pull that fix for PCL into the release or not. Its a relatively minor point, but it should also be exceedingly low risk, since all it does is alter a glyph name | 14:40.03 |
| HenryStiles | paid a fortune for scalped tickets but worth it for a one time thing | 14:40.47 |
| chrisl | kens: Yeh, I'll pull that in - it looks pretty benign | 14:41.59 |
| kens | Should be yes | 14:42.05 |
| | It was a lot harder to figure out what was going on | 14:42.35 |
| | Took me a while to realise I was getting different results with GS and Acrobat | 14:42.48 |
| chrisl | Because Acrobat :-( | 14:42.54 |
| kens | Well I was cutting the file down and more or less arbitrareily using GS or Acrobat to view the result, and the problem kept appearing and disappearing.... | 14:43.30 |
| chrisl | So far I have Robin's image dropouts fix, and your PCL->pdfwrite text change pulled onto the release branch | 14:46.37 |
| | I still plan rc2 for Wednesday, but we can reassess based on the XPS issue before I go ahead with that | 14:48.05 |
| kens | Frtom what Michael says, the problem is that the ICC profile is not valid in PDF files | 14:48.38 |
| | So we've *always* produced a broken PDF file | 14:48.50 |
| | It sjust that other changes have revealed that in GS when it was previously hidden | 14:49.05 |
| | Its a rare problem I'd say, but again probably a pretty reliable fix, all I need is for Michael to give me a way to determine if the ICC profile is suitable. If not we'll drop back to device space and everything will work | 14:49.52 |
| chrisl | It's really a time thing - given it's not a regression, and not a crash, I don't want to hold up the release significantly. OTOH, a few days isn't going to make much difference | 14:51.56 |
| kens | I wouldn't hold up the release for this. If Michael and I can put it together before Wednesday then its probably OK to include it, if not then we'll just let it slide to the next release. I really don't want to do yet another round of testing | 14:53.00 |
| Robin_Watts | Sorry ray_laptop. I stepped away for a mo. | 16:05.27 |
| ray_laptop | Robin_Watts: NP. I am looking at the confusing (I *hate* this style of code, but...) extra_xform.h and there seem to be some threading holes | 16:06.40 |
| Robin_Watts | extra_xform.h being the chameleonic header used for generating the optimised transforms, right? | 16:07.20 |
| ray_laptop | Robin_Watts: first, the memcpy from CacheIn and CacheOut looks like a hole between the two operations (or even during them memcpy) | 16:08.24 |
| Robin_Watts | ray_laptop: The cache never gets updated. | 16:08.49 |
| | It's only the initial value that gets copied out repeatedly. | 16:08.59 |
| | The code that copies back is #if 0'd out :) | 16:09.24 |
| | You are right in that if we copied back there would be a threading hole. | 16:09.44 |
| HenryStiles | mvrhel_laptop: you have time for a phone chat? | 16:10.09 |
| Robin_Watts | Hence the comment at the end of the function, just before #if 0 | 16:10.20 |
| mvrhel_laptop | HenryStiles: sure | 16:10.23 |
| | HenryStiles: let me reset my phone | 16:11.31 |
| | it says no service | 16:11.35 |
| HenryStiles | mvrhel_laptop: yeah got your voice mail | 16:11.58 |
| mvrhel_laptop | ok now I have signal | 16:12.25 |
| | my iphone does that sometimes | 16:12.45 |
| | just decides it does not want to connect to cellular | 16:12.59 |
| Robin_Watts | guesses ray is heading coffeewards. | 16:22.45 |
| ray_laptop | Robin_Watts: OK, I was confused by the pointers is the NO_UNPACK NO_PACK cases sprinkled in there. BTW, line 331 looks wrong (in the #if 0 code) | 16:23.12 |
| Robin_Watts | 331 is the end of the file for me. | 16:23.41 |
| ray_laptop | Robin_Watts: sorry, I keep looking at the wrong part of the vim status bar. line 298? | 16:24.02 |
| | copying into the CacheOut from prevIn | 16:24.23 |
| Robin_Watts | ray_laptop: Yeah, that looks wrong. CacheIn instead? | 16:24.39 |
| ray_laptop | yes, not that it matters to us. | 16:24.54 |
| Robin_Watts | ray_laptop: If you can see a way to improve the readability of any of this, great. | 16:25.06 |
| | I couldn't see a way to get the same efficiency without working in this way (short of manually writing all the different versions) | 16:25.45 |
| ray_laptop | Robin_Watts: then the other thing: // the caller guarantees us that the cache is always valid on entry -- how does the caller guarantee that ? | 16:30.32 |
| Robin_Watts | ray_laptop: bear with me a mo. | 16:32.18 |
| ray_laptop | suspects that he caller guarantees us that the cache is always valid on entry sets it | 16:32.55 |
| | and nobody ever resets it | 16:33.18 |
| Robin_Watts | ray_laptop: Yes, I suspect it gets set initially and then never gets reset. | 16:35.20 |
| ray_laptop | in cmsCreateExtendedTransform | 16:36.06 |
| Robin_Watts | Yes. (Just got there myself :) ) | 16:36.46 |
| ray_laptop | and the second part of the comment line 227 in extra_xform.h was just part of the picture when we change the representation: if the representation is changed, the cache is reset. | 16:38.13 |
| | which is still WIP | 16:38.28 |
| Robin_Watts | ray_laptop: Urm... | 16:39.53 |
| | cmsChangeBuffersFormat probably needs to reset the cache. | 16:40.08 |
| ray_laptop | Yes, and more (as we discussed) such as clone the xform with new procedures | 16:41.37 |
| | :q | 16:41.53 |
| mvrhel_laptop | brb | 16:42.42 |
| Robin_Watts | I suspect that we're actually broken at the moment even in the way we use it. | 16:43.39 |
| | The existing code, running in single threaded mode, calls cmsChangeBufferFormat. | 16:44.06 |
| | And that should invalidate the cache | 16:44.17 |
| | but it doesn't. | 16:44.21 |
| | which makes me think that we *could* get bad results out. | 16:44.38 |
| | (very unlikely, but possible) | 16:44.44 |
| ray_laptop | Robin_Watts: invalidate or update the CacheOut using CacheIn values | 16:45.03 |
| Robin_Watts | ray_laptop: I should have said "revalidate". | 16:45.28 |
| | by which I meant "updated the cacheOut using cacheIn values" | 16:45.44 |
| ray_laptop | but the bigger problem, of course, is that we can't share contexts with different formats in or out | 16:46.40 |
| Robin_Watts | contexts? | 16:48.02 |
| | The big problem is that we can't currently allow a transform to be used in more than one thread at a time, with different formats. | 16:48.57 |
| | adding a function to clone the transform would solve that. | 16:49.27 |
| | OK, now I look at this code, I think we're OK. | 16:49.48 |
| | 8 bit data is unpacked to 16 bit data. | 16:50.05 |
| | so the cache is still valid. | 16:50.13 |
| | We'd have a problem if we ever changed from (say) 16bit to float. | 16:50.34 |
| | But float transforms don't use the cache. | 16:50.58 |
| | So, still fine. | 16:51.06 |
| ray_laptop | Robin_Watts: sorry cmsContext == hTRANSFORM == _cms_transform_struct | 16:52.20 |
| Robin_Watts | cmsContext most definitely is NOT == hTRANSFORM. | 16:53.36 |
| ray_laptop | Robin_Watts: I don't follow "8 bit data is unpacked to 16 bit data. so the cache is still valid." | 16:54.18 |
| Robin_Watts | The context is a magic void * that is fed through to the allocation functions unchanged. | 16:54.21 |
| | In gs, the context is the gs_memory_t, basically. | 16:54.32 |
| | In MuPDF it's an fz_context. | 16:54.40 |
| | ray_laptop: OK, every transform function in lcms works in 3 phases. | 16:55.01 |
| | for each pixel, it 'unpacks' the pixel into either float or 16bit. | 16:55.21 |
| | then it does the transform. | 16:55.33 |
| | then it packs the result back out to the required format. | 16:55.47 |
| | The caching happens by comparing the result of the 'unpack' phase to the previous 'unpacked' results. | 16:56.33 |
| ray_laptop | yes, and the "xform" bakes all of the pack..xform..unpack into a function defined in extra_xform.h | 16:56.48 |
| Robin_Watts | If you give it 16 bit data, then the unpack function is basically nothing. | 16:56.56 |
| | (or a copy, rather) | 16:57.07 |
| | If you give it 8 bit data, then the unpack function is f(x) = (x<<8)|x or something like that. | 16:57.30 |
| | So swapping between 8 or 16 bit data means the cache values stay valid. | 16:57.53 |
| ray_laptop | so as long as cloning a transform with a new pack or unpack (re)sets the cache in that clone, fine | 16:58.24 |
| Robin_Watts | No. | 16:58.40 |
| | However you clone a transform, the cache remains valid. | 16:58.56 |
| ray_laptop | because the cache is always 16-bit data | 16:59.31 |
| Robin_Watts | Yes. | 16:59.36 |
| ray_laptop | OK | 16:59.40 |
| Robin_Watts | Took me a while to work that through in my head, but I think we're fine. | 16:59.56 |
| | When we DO add cloning, we should move the cache into the clone, cos that means we can write the cache back safely. | 17:00.21 |
| | (well, maybe) | 17:00.35 |
| | we'd have to say one clone per thread. | 17:00.46 |
| ray_laptop | uh, no. we still want to share a clone among threads | 17:00.53 |
| Robin_Watts | Do we though? | 17:01.19 |
| | The important bit that we want to avoid is duplicating the large inner tables. | 17:01.40 |
| ray_laptop | but presuming that creating a clone of a link profile is fairly fast, then the tradeoff is in memory consumption | 17:01.49 |
| | so all of the internal tables need refcount maintained? | 17:02.31 |
| Robin_Watts | Our per thread clones will basically be pack, unpack and transform pointers, with the cache entries. | 17:02.35 |
| ray_laptop | (if they are not copied) | 17:02.41 |
| Robin_Watts | and a pointer to a ref counted 'core'. | 17:02.43 |
| | Yes, exactly. | 17:02.45 |
| | We have some options to consider. | 17:03.03 |
| | but we're safe at the moment, which is the main thing. | 17:03.11 |
| ray_laptop | OK, as long as the contents of the core are "read-only" we'd be OK | 17:03.16 |
| Robin_Watts | yes. | 17:03.21 |
| ray_laptop | safe at the moment because gscms_is_threadsafe returns false :-) | 17:03.39 |
| Robin_Watts | If you can see a way to improve the readability of this stuff, without harming the efficiency, I'd be interested. | 17:03.51 |
| | ray_laptop: Yes. | 17:04.04 |
| mvrhel_laptop | ray_laptop: so are we thread-safe in gs with lcmsart? Do we need to write the clone operation first? | 17:10.11 |
| Robin_Watts | mvrhel_laptop: We need to write the clone function in order to be able to allow gscms_is_threadsafe to return true safely. | 17:10.59 |
| mvrhel_laptop | ok. maybe I should do that. I want to get this thing up and running before I write the paper so that we can show some timing results | 17:11.23 |
| | I mean we could use mupdf too | 17:11.40 |
| | but here gs is nice since we can easily turn off and on multi-threaded cmm support | 17:12.26 |
| | and see what effect it has | 17:12.33 |
| | ray_laptop: if you are not doing the clone operation, I will do it right after I wrap up this one thing for ken (which should just take a moment) | 17:14.08 |
| Robin_Watts | mvrhel_laptop: Given your workload, would it make sense for me to look at that ? | 17:20.49 |
| mvrhel_laptop | Robin_Watts: if you want to do it, I am fine with that | 17:21.12 |
| Robin_Watts | I will have a bash. | 17:21.26 |
| mvrhel_laptop | Robin_Watts: ok sounds good | 17:28.36 |
| | Robin_Watts: So I understand as I write this up. By passing the context through all these operation in lcms, we then can guarantee that the memory allocations (and deallocations) occur in each calling thread's proper memory chunk thereby avoiding issues that malloc is not safe. I don't think gs multi threading uses the base memory in gs that has the mutex if I understand it correctly. ... | 17:54.44 |
| | ... Ray may have a comment here. | 17:54.45 |
| | | 17:54.47 |
| | ray_laptop: ^^ | 17:54.59 |
| Robin_Watts | mvrhel_laptop: We ensure that the caller gets the ContextID back that it passed it :) | 17:55.34 |
| | mvrhel_laptop: We ensure that the caller gets the ContextID back that it passed in :) | 17:55.38 |
| | For gs, that means that every thread gets back the memory pointer that it passed in. | 17:56.00 |
| | For MuPDF, it means that the allocators are called with the correct exception stack. | 17:56.24 |
| | For other callers, it avoids the case where people call cmsDoSomeOperation(foo) , and that calls back to the registered allocation function and gets passed bar instead. | 17:57.17 |
| | More generally we are fixing the case where 2 threads try to use the same profile at the same time, and get bad results because of multiple simultaneous accesses to the cache. | 17:58.31 |
| | and we're faster. | 17:58.39 |
| | (cos of our more optimised pack/transform/unpack functions) | 17:59.01 |
| | mvrhel_laptop: Probably we can also take the opportunity to clean the API slightly. | 18:01.12 |
| mvrhel_laptop | Robin_Watts: ok. So in the case of gs, the threads use different memory chunks that ensure we don't have issues. In the case of mupdf, each thread has its own exception stack that needs to be consistently used | 18:01.26 |
| Robin_Watts | yes. | 18:01.36 |
| | Rather than having cmsBlahCTX and cmsBlahTHR etc, we can just standardise on cmsBlah now. | 18:01.55 |
| mvrhel_laptop | Robin_Watts: I am going to need you to help in writing up the optimized pack/transform/unpack | 18:02.04 |
| Robin_Watts | mvrhel_laptop: Sure. | 18:02.11 |
| mvrhel_laptop | Robin_Watts: yes, I agree that we should clean that up now that we are forking | 18:02.30 |
| | I need to figure out a easy way to make a pdf file with lots of profiles for testing this. Adobe illustrator (at least my version) and Design have limited capabilities | 18:04.10 |
| | I wonder if the newer versions have improved | 18:04.26 |
| Robin_Watts | mvrhel_laptop: This is why God gave us text editors :) | 18:04.47 |
| mvrhel_laptop | yes. I suppose. I was thinking I could use mupdf create | 18:05.07 |
| Robin_Watts | yeah. | 18:05.12 |
| mvrhel_laptop | and add icc support | 18:05.13 |
| | That would probably not take too long | 18:05.27 |
| | I just want to do some rect fills and assign profiles | 18:05.36 |
| Robin_Watts | Can you create a document with the content on different pages? | 18:05.52 |
| | Then editing that to roll the content onto a single page is simple. | 18:06.09 |
| mvrhel_laptop | you mean page 1 has icc profile 1, page 2 has icc profile 2 etc | 18:06.24 |
| Robin_Watts | Yes. | 18:06.27 |
| mvrhel_laptop | yes that would be easy | 18:06.34 |
| | right | 18:06.36 |
| Robin_Watts | Then we pretty much just edit the streams together. | 18:06.40 |
| mvrhel_laptop | then we could just change the reference | 18:06.44 |
| Robin_Watts | yeah. | 18:06.47 |
| mvrhel_laptop | that would be faster... | 18:06.53 |
| Robin_Watts | It builds... what did I miss? :) | 18:07.09 |
| mvrhel_laptop | nice | 18:07.15 |
| | Robin_Watts: thanks for the suggestion | 18:07.23 |
| Robin_Watts | and it ran. | 18:07.53 |
| mvrhel_laptop | cool | 18:11.24 |
| Robin_Watts | Now to figure out the /* FIXME: LOCK */ and /* FIXME: UNLOCK */ lines :) | 18:12.01 |
| mvrhel_laptop | Robin_Watts: we will want to be able to add the cloned link to the cache and we will want to include if the link is 8 or 16 bit in the hash that is used for the link cache | 18:12.29 |
| | and obviously look for it in the cache | 18:12.44 |
| Robin_Watts | I may come to you at that point :) | 18:13.02 |
| mvrhel_laptop | ok | 18:13.33 |
| Robin_Watts | Ok, so there is no central shared mutex I can use in lcms. | 18:13.56 |
| | It appears that the user can pass in a MutexPlugin to provide a mechanism for creating/destroying/locking/unlocking mutexes. | 18:14.55 |
| | but we'd have to store those somewhere. | 18:15.04 |
| | I could put a mutex in every transform. | 18:15.12 |
| | And we could lock/unlock them as the transform is used. | 18:15.42 |
| | (or cloned) | 18:15.52 |
| mvrhel_laptop | so the transform should not need to be locked to be used should it? | 18:16.16 |
| Robin_Watts | actually, I don't like that. | 18:16.20 |
| | Indeed, it shouldn't need to be locked to be used. | 18:16.31 |
| | Well... | 18:16.36 |
| | I now have a cmsTRANSFORM that contains a pointer to the cmsTRANSFORMCORE | 18:16.51 |
| | and the CORE is reference counted. | 18:16.59 |
| mvrhel_laptop | oh I thought we were thinking of doing a copy | 18:17.11 |
| Robin_Watts | I need a mutex *somewhere* to protect reference counted changes. | 18:17.30 |
| mvrhel_laptop | right | 18:17.34 |
| | so during creation and destruction you will need to lock | 18:17.44 |
| Robin_Watts | I thought the copy was being considered as a stepping stone to getting to the (nicer) ref counted version. | 18:17.56 |
| | but I jumped right in. | 18:18.04 |
| | yes. | 18:18.13 |
| | So I am pondering having ever cmsTRANSFORMCORE having a mutex in it. | 18:18.30 |
| mvrhel_laptop | which should be fine. That will not occur too often | 18:18.30 |
| Robin_Watts | (in the absence of a more global place) | 18:18.47 |
| | The attraction of having a mutex in the cmsTRANSFORM (not CORE) and locking/unlocking it during use is that that way anyone that didn't care too much could still use stuff in a threadsafe manner without thinking about it (just at the cost of some inefficiency if they got it wrong) | 18:19.54 |
| ray_laptop | Robin_Watts: you mean a lock/unlock on every cmsDoTransform -- that sounds expensive | 18:30.04 |
| Robin_Watts | ray_laptop: lock/unlock should be very cheap with no contention. | 18:30.38 |
| | but I'm not doing that for now. | 18:30.48 |
| mvrhel_laptop | heading out for lunch. Writing this paper is a tight rope. I don't want to be too critical of the existing code but I do have to point out its shortfalls | 18:51.13 |
| Robin_Watts | ray_laptop: Did you push the memento change? | 18:55.44 |
| | (the mutex) | 18:56.11 |
| ray_laptop | Robin_Watts: no, I have it on my branch for gsicc changes that still give me different diffs to HEAD with NumRenderingThreads>1 | 18:56.42 |
| Robin_Watts | ok. | 18:56.48 |
| ray_laptop | Robin_Watts: I guess it would be good to push, so chrisl can (maybe) cherry-pick it for RC2 | 18:57.22 |
| Robin_Watts | ray_laptop: While I think it would be safe to pull (after all, nothing uses memento in standard builds), let's not rock the boat for the release. | 18:58.38 |
| ray_laptop | Robin_Watts: OK, pushed | 18:58.41 |
| | chrisl: can decide whether or not to cherry-pick it | 18:59.05 |
| Robin_Watts | ray_laptop: Thanks. | 18:59.06 |
| | yeah. | 18:59.08 |
| | OK, my lcms2 changes are testing now. | 18:59.30 |
| | http://git.ghostscript.com/?p=user/robin/ghostpdl.git;a=commitdiff;h=e9595e7061ae807302a8ae0406cf54e8fd59f8a8 | 18:59.56 |
| ray_laptop | Robin_Watts: with gscms_is_threadsafe changed in gsicc_lcms2art.c yet ? | 19:00.30 |
| Robin_Watts | ray_laptop: No. | 19:00.41 |
| | I've changed lcms2. | 19:00.46 |
| ray_laptop | Robin_Watts: oh, not gs to use it. OK | 19:01.00 |
| Robin_Watts | The next step is to change the gs code that calls lcms2 to clone contexts. | 19:01.02 |
| | s/contexts/transforms/ | 19:01.11 |
| | then we can try changing that setting. | 19:01.19 |
| ray_laptop | Robin_Watts: sounds like what I can do as part of getting my changes in | 19:01.28 |
| Robin_Watts | sure. | 19:01.33 |
| ray_laptop | Robin_Watts: what is cach<E9> ? | 19:09.35 |
| velix | Did you get my message from yesterday? I thought, pdfwrite would rewrite rectangles to paths or something when processing (concat PDFs etc.), but it doesn't do so. The output still had a rectangle (I checked the uncompressed PDF code). | 19:50.12 |
| ray_laptop | Robin_Watts: for the next phase of change to lcms2art, once I change to using cmsCloneTransformChangingFormats should I remove cmsChangeBuffersFormat (i.e., what Marti wanted to do, but we talked him out of it) ? | 19:50.53 |
| Robin_Watts | ray_laptop: I would think so. | 19:51.16 |
| ray_laptop | Robin_Watts: OK, I thought that was the plan. Just checking. So lcms2mt won't have that, but will have ...Clone... which is hardly any more expensive | 19:52.40 |
| | and one we get it to really work MT, we can finally change the name :-) | 19:53.16 |
| | we might get some pulls from the Java world if they are currently using lcms2 without sharing profiles, but then again, the Java world isn't concerned about memory usage, is it? | 19:55.07 |
| | and even less about performance hits for re-creating link profiles | 19:55.45 |
| RonL_ | clear | 22:08.21 |
| | Forward 1 day (to 2018/03/13)>>> | |
Log of #ghostscript at irc.freenode.net.