| | <<<Back 1 day (to 2013/10/31) | 2013/11/01 |
| ray_laptop | just getting around to glancing at the bmpcom | 00:00.18 |
| | bmpcmp | 00:00.22 |
| Robin_Watts | ray_laptop: It's only ever psdcmyk with clist that's wrong. | 00:00.39 |
| | i.e. our one planar device with clist. | 00:00.51 |
| | and it's because of clist_plane_depth being wrong. | 00:01.03 |
| | I sent you a couple of emails with my findings in earlier before I headed off. | 00:01.24 |
| ray_laptop | Robin_Watts: OK. Are you investigating, or are you done for the day. I am glad to fig into it, now | 00:01.44 |
| | Robin_Watts: Oh, Thanks. I'll read the email | 00:01.55 |
| Robin_Watts | I'm off to bed now. | 00:02.00 |
| ray_laptop | emails | 00:02.01 |
| | Robin_Watts: OK. Sleep well. | 00:02.14 |
| Robin_Watts | If you don't solve it today, feel free to throw it at me for tomorrow. | 00:02.26 |
| ray_laptop | mvrhel: (for the logs) Happy Halloween. Hope you and your kids have fun and stay safe! | 00:56.17 |
| | mvrhel: (for the logs) Your fix lets cust 532's simulator complete the file | 00:57.07 |
| | mvrhel: (for the logs) One issue is that when the allocation fails in gsicc_load_profile_buffer, it returns "-1" (gs_unknownerror) rather than VMerror which means that we don't know the reason for the error. It doesn't even use the gs_unknownerror #define -- is just assumes that returning -1 is good enough | 01:06.12 |
| | mvrhel: this is without your fix, of course. | 01:06.53 |
| | mvrhel: ideally, we'd like to be able to free up whatever we can and bubble a VMerror up. | 01:07.46 |
| | mvrhel: I will look at a fix for them, but please consider this approach (VMerror if we know an allocation fails) rather than returning -1 | 01:09.15 |
| | back to the alignment issue... | 01:09.27 |
| dug074 | Wow a real live IRC channel still exists? | 02:54.10 |
| | ... guess not :-| | 02:54.46 |
| sebras | dug074: it is alive, but you might have to wait a while for people to wake up... | 03:40.07 |
| Robin_Watts | So, we have this function gx_device_raster, which is designed to return us either the padded or unpadded raster for a line. | 14:08.49 |
| | unpadded = width rounded up to bytes, padded = what we mean by raster generally. | 14:09.09 |
| | Except in the new scheme with padding, it won't work. | 14:09.32 |
| | Rather than simply adding new functions in, I wonder if we should just make this one work. | 14:09.48 |
| | To make it work, either we need to add a 'raster' value to every device, or we need to make it so that it can read the align/pad for every device and do that calculation itself. | 14:11.27 |
| | Currently the align/pad is done by a gxdso. | 14:11.38 |
| | Maybe we should move the align/pad stuff to be entries in gx_device *. 0 would mean 'default', so all existing devices would work. | 14:12.22 |
| henrys | Robin_Watts: do we have any sense of what the alignment is going to buy us? | 14:53.53 |
| Robin_Watts | henrys: We do not. | 14:54.03 |
| | but, padding is important, regardless, I feel. | 14:54.25 |
| | And we *ought* to be able to offer people aligned buffers really. | 14:54.40 |
| mvrhel_laptop | Robin_Watts: how is that I avoided this issue with the SSE2 stuff that I did? Is it due to the fact that I was doing my own allocations and handled the unaligned case special? | 14:54.51 |
| Robin_Watts | mvrhel_laptop: exactly. | 14:55.05 |
| mvrhel_laptop | ok | 14:55.07 |
| Robin_Watts | With the process_page stuff the key idea (well one of the key ideas) is to get the buffers so they can accessed 'in-place' with SSE. | 14:55.41 |
| mvrhel_laptop | you can still do that cant you? you just need to do an unaligned operation at the start and end of the buffer | 14:56.11 |
| | or am I missing something | 14:56.43 |
| Robin_Watts | mvrhel_laptop: Indeed, but do we really want to foist that onto our users? | 14:57.05 |
| mvrhel_laptop | well SSE2 in general requires some extra work | 14:57.21 |
| | and having to understand how you data is set up is not too much to ask | 14:57.35 |
| Robin_Watts | And in 801s case they have to combine the data from the buffer, plus a noise table. | 14:57.37 |
| | The noise table is aligned in memory. | 14:57.42 |
| | so if the data isn't, then we'll always end up with one of the loads having to be unaligned. | 14:58.01 |
| | If we can get the buffers aligned, this becomes MUCH simpler all around. | 14:58.23 |
| mvrhel_laptop | right. | 14:58.25 |
| chrisl | Seems like a lot of effort for one customer....... | 14:58.59 |
| mvrhel_laptop | well, hopefully this will be useful for toher | 14:59.29 |
| | others | 14:59.31 |
| | henrys: to answer you question about what it will buy us. I don't have any hard numbers but when I was doing our HT SSE2 stuff the aligned operations where noticeably faster | 15:00.39 |
| | s/where/were/ | 15:00.48 |
| henrys | I wonder if whatever buffer we render into - clist or full frame should be 16 byte aligned and padded. | 15:02.09 |
| mvrhel_laptop | Robin_Watts: I guess I had copied the periodic chunck of the noise table into an aligned buffer | 15:02.21 |
| | in my case, I could have been any place on the page at any time | 15:02.43 |
| | in your case you are doing the whole page so that is a little different | 15:02.57 |
| | i.e. I could not take advantage of having the HT mask in aligned memory to start with | 15:03.42 |
| | but you can. However, I do wonder what the cost of the memcpy really would be to get things aligned | 15:04.51 |
| | prior to doing the SSE2. i.e. do the special unaligned operation at the start and end of the raster buffer. copy the mask part you need into a re-aligned buffer | 15:06.02 |
| | and then do the aligned operation | 15:06.10 |
| | does that make sense Robin_Watts ? | 15:06.18 |
| Robin_Watts | mvrhel_laptop: Yes, we could copy the noise into a co-aligned thing, and then do alignment at the start/end. | 15:07.03 |
| mvrhel_laptop | right | 15:07.10 |
| | I am just bouncing off an idea to see if this is less work | 15:07.29 |
| Robin_Watts | but if we can get aligned buffers anyway, it's a hell of a lot easier :) | 15:07.34 |
| mvrhel_laptop | without any serious performance hit | 15:07.41 |
| Robin_Watts | I'd far rather see the system do just a bit more work than every caller have to do the same amount. | 15:08.11 |
| | And having looked at this code, it seems to me that we are in pretty bad shape here anyway. | 15:08.35 |
| henrys | Robin_Watts: is there any problem with just requiring all scan lines have the needed padding and alignment device wide? | 15:08.45 |
| mvrhel_laptop | ok. again just making a suggestion | 15:08.50 |
| Robin_Watts | I can't help feeling that doing this 'right' will give us overall cleaner code. | 15:09.02 |
| mvrhel_laptop | yes | 15:09.10 |
| | I agree | 15:09.20 |
| Robin_Watts | henrys: How does that differ from what I am suggesting? | 15:09.25 |
| mvrhel_laptop | bbiab | 15:09.33 |
| henrys | Robin_Watts: oh I thought you were special casing | 15:09.46 |
| Robin_Watts | Every buffering thing allocated by the device will have the needed padding and alignment. | 15:09.55 |
| henrys | the 801 device | 15:09.59 |
| Robin_Watts | The problem is we lose out massively if we require that for all buffers system wide. | 15:10.23 |
| | as glyphs through the clist then get really bad compression. | 15:10.36 |
| | All ray and I have been trying to do is to retrofit something to the system whereby any device (in this case 801s) can say "whenever you allocate buffers for me, make sure they are aligned to A, and padded to P" | 15:11.19 |
| henrys | I meant all frame buffers and and clist render output buffers | 15:11.34 |
| | not all buffers | 15:12.03 |
| ray_laptop | morning, all | 15:12.22 |
| Robin_Watts | henrys: You mean align all buffers of that type without depending on the device ? | 15:12.43 |
| ray_laptop | The nice thing about their BNM is that it is 128 bytes, so once you have aligned copies, you are set, right ? | 15:13.04 |
| henrys | Robin_Watts: actually we get away with making it a requirement for all memory devices, right? | 15:13.15 |
| Robin_Watts | henrys: I don't think so. | 15:13.33 |
| | ray_laptop: Yes. | 15:13.35 |
| kens | Hi Ray | 15:13.37 |
| ray_laptop | Robin_Watts: as far as glyphs, in the cache, they know the bounds and even though the mem device they are painted into, the cache (and clist) can easily discard the empty tail. | 15:18.53 |
| | Hi, kens | 15:19.02 |
| | kens: I made it in before you started, for a change :-) | 15:19.22 |
| | s/started/left/ OOPS | 15:19.34 |
| kens | :) | 15:19.39 |
| ray_laptop | maybe I was thinking "before you started your weekend". I sure don't know. Coffee hasn't hit the brain yet, clearly | 15:20.23 |
| Robin_Watts | ray_laptop: Except the clist doesn't currently discard the tail when compressing glyphs. I believe. | 15:20.56 |
| ray_laptop | Robin_Watts: it doesn't treat glyphs uniquely, but you are right, it doesn't scan for extra. But the place to do it, IMHO, is in the glyph cache, so we get better cache hit rate and then the bitmap fed to the device (clist) will be the trimmed one | 15:24.11 |
| Robin_Watts | ray_laptop: Possibly. | 15:24.34 |
| | But i do feel that alignment and padding should be a device specific thing, not a system wide thing, as I think henrys was suggesting. | 15:24.56 |
| | I mean, I could imagine a printer with a DMA engine that required all scanlines to be 256 byte aligned or something odd like that. | 15:25.31 |
| henrys | Robin_Watts: yea i suppose you are right. | 15:26.09 |
| ray_laptop | Robin_Watts: I assume that I still need to fix the clist planar alignment, right ? | 15:26.40 |
| | Robin_Watts: BTW, for benchmarks for cust 801 (or any Japanese customer) I recommend the JEITA files | 15:27.07 |
| Robin_Watts | ray_laptop: I'm playing with a different way of doing it. | 15:27.11 |
| ray_laptop | Robin_Watts: how's that ? | 15:27.24 |
| Robin_Watts | Given that we have a gx_device_raster function, I kinda feel that that ought to give the right result. | 15:27.39 |
| | So I want to add a 'pad' and and 'align' field into every gx_device. | 15:27.57 |
| ray_laptop | Robin_Watts: yes, agreed. But with a DSO we would need the target deviec | 15:28.09 |
| Robin_Watts | And I think I need to add a 'num_planes' in there as well. | 15:28.21 |
| | 0 in those values would keep the existing behaviour. | 15:28.44 |
| ray_laptop | Robin_Watts: I also think that would be better. And a *LOT* simpler than trying to keep things sync'ed up with the buf_device. | 15:28.58 |
| Robin_Watts | That would then let me remove the gxdso for is_planar. | 15:29.12 |
| ray_laptop | Robin_Watts: but it's sort of useless for non-raster devices | 15:29.39 |
| Robin_Watts | I might well run full tilt into another hole full of nasty spikes, but it's got to be tested. | 15:29.46 |
| | ray_laptop: Right, so non-raster devices leave it set to 0. No harm, no foul. | 15:30.01 |
| | The values say "whenever we allocate buffers for rendering of such things, use buffers of this format". | 15:30.26 |
| | I mean, pdfwrite probably has color_info set up right, even though the bit depths probably aren't used? | 15:31.01 |
| ray_laptop | Robin_Watts: if it's in the gx_device struct after the usual part, the initializer macros (given the way C works, that we rely heavily on) the extra params will be set to 0, right ? | 15:31.29 |
| Robin_Watts | right. | 15:31.54 |
| | yeah, I'm hoping this should be zero impact for everyone that's using the standard init macros. | 15:33.21 |
| ray_laptop | Robin_Watts: so we'd add align_mod, pad, raster, and num_planes ? | 15:33.31 |
| Robin_Watts | Yes. | 15:33.38 |
| | Why does page_procs say "must be last" ? | 15:33.48 |
| JakeSays | in a pdf, is the object type of an image mask still Image? | 15:33.59 |
| henrys | Robin_Watts: there are a few devices not using the macros right but we'll fix it. | 15:34.07 |
| Robin_Watts | especially when they aren't. | 15:34.10 |
| | henrys: yeah, I avoid the macros like a plague :) | 15:34.21 |
| henrys | I'd rather things break than use the dreaded macros ;-) | 15:34.48 |
| ray_laptop | Robin_Watts: I think the comment relates to "end of std_device body", which just means that it relates to the macros | 15:36.02 |
| | AFAICT, we can add something even after "procs" | 15:36.28 |
| Robin_Watts | I am trying adding it after procs now. | 15:36.43 |
| henrys | anyway I believe marcos is still running the "all" device test that should give us some security | 15:36.59 |
| Robin_Watts | Ugh, no, after procs is a bad idea. | 15:38.02 |
| ray_laptop | Robin_Watts: why? does some code use that as a marker ? | 15:38.24 |
| Robin_Watts | I think that'll break more stuff. | 15:38.38 |
| ray_laptop | Robin_Watts: any specific breakage you noticed ? | 15:41.44 |
| Robin_Watts | ray_laptop: Let me play for a bit before I waste everyones time. | 15:42.17 |
| ray_laptop | Robin_Watts: OK. | 15:43.25 |
| Robin_Watts | I will be heading off slightly early today as I have an old school friend coming round. I'll be about tomorrow to play with this some more though. | 15:44.19 |
| ray_laptop | Robin_Watts: as far as the solution to getting the "real" raster for clist_rasterize_lines is to call the 'size_buf_device' since that returns the gx_device_buf_space_t which has 'raster' | 15:47.00 |
| | that way there is no need for clist_plane_raster | 15:47.23 |
| | right ? | 15:47.32 |
| Robin_Watts | ray_laptop: Sounds plausible. But I have other problems with your patch... Let me try to see what they were... | 15:48.03 |
| | (I suspect these aren't your fault, they are just existing problems that your patch brings to light) | 15:48.20 |
| | In gz_default_setup_buf_device, we pass 'bytes_per_line' in. | 15:49.19 |
| ray_laptop | maybe. The clist has been "touched" by a lot, and the assumptions baked into 'bitmap_raster' don't help | 15:49.32 |
| Robin_Watts | and then completely ignore it all the way through the function, using our own 'raster' value. | 15:49.47 |
| | until right at the end, we calculate an offset using raster, but pass 'bytes_per_line' into the sub function. | 15:50.16 |
| ray_laptop | into set_line_ptrs | 15:50.56 |
| | right. | 15:51.01 |
| Robin_Watts | I suspect we should if (bytes_per_line != 0) raster = mdev->raster = bytes_per_line at the top. | 15:51.35 |
| | and then use raster everywhere. | 15:51.42 |
| ray_laptop | The only thing I use bytes_per_line for in set_line_ptrs is to make sure that it isn't too large | 15:51.50 |
| Robin_Watts | If mdev->raster is always correct, then why do we have bytes_per_line at all ? | 15:53.41 |
| ray_laptop | I really worried about gx_get_bits_copy because it gets called with gx_device_raster from mem_get_bits_rectangle which seems wrong | 15:55.20 |
| Robin_Watts | This is part of the reason I'd like to move to a system where gx_device_raster is always correct :) | 15:55.50 |
| ray_laptop | and it would not calculate it, but would just return dev->raster ? | 15:57.58 |
| Robin_Watts | ray_laptop: It would calculate it every time. | 15:58.40 |
| | from width/pad/align/num_planes | 15:58.48 |
| ray_laptop | Robin_Watts: I'm not sure why setup_buf_device gets bytes_per_line, particularly since the other buf_procs don't get that. It's lost in history, I guess | 15:59.33 |
| Robin_Watts | yeah. | 15:59.41 |
| ray_laptop | Robin_Watts: calculate it and set dev->raster ? | 15:59.52 |
| Robin_Watts | How do we remember to reset dev->raster when we change width? or num_planes? | 16:00.28 |
| | or color_info | 16:01.12 |
| ray_laptop | I think the mem devices, at least, want a 'raster' since it gets used on every fill_rectangle to use as the line stride | 16:01.16 |
| Robin_Watts | ray_laptop: Right. I'm not averse to the mem devices having a 'raster' stored. | 16:01.32 |
| | but to have a raster in the top level gx_device that is kept up to date seems error prone. | 16:01.53 |
| | the mem devices can set raster on opening, and that will be good for ever. | 16:02.10 |
| ray_laptop | width change closes the device, as does depth change. Changing the planar should do the same, IMHO | 16:02.13 |
| | Robin_Watts: OK. since the device must be open to paint, but we need to make sure that changing num_planes (set up as planar) also causes the device to cliose | 16:03.32 |
| | because the pad and alignment apply to more lines, right | 16:04.04 |
| Robin_Watts | ray_laptop: The only place where num_planes should get set is in open_device, right ? | 16:04.09 |
| ray_laptop | It may already be doing that | 16:04.10 |
| | I thought that UsePlanarBuffer was a device param for some devices | 16:04.53 |
| Robin_Watts | right, and based on that, we either call prn_open_device or prn_open_device_planar within open_device. | 16:05.53 |
| | so it only actually takes effect during the device open, I believe. | 16:06.21 |
| ray_laptop | Robin_Watts: so, unlike other parameters that affect the geometry (eg., width) the put_params of UsePlanarBuffer on an open device is ignored ? | 16:07.30 |
| Robin_Watts | Let me check. | 16:07.46 |
| | UsePlanar buffer seems to actually take effect in bmpa_writer_open (what does that device do?) | 16:08.48 |
| ray_laptop | Robin_Watts: ignore the bmpa device. It is deprecated, and soon to be deleted | 16:09.11 |
| Robin_Watts | in ppm_open it controls planar or not. | 16:09.14 |
| | And that's it. | 16:09.33 |
| | So it only affects things when the device is next opened. | 16:09.45 |
| ray_laptop | Robin_Watts: please see gdev_prn_put_params. It calls gdev_prn_maybe_realloc_memory | 16:10.20 |
| Robin_Watts | I see no reference to UsePlanarBuffer in there. | 16:11.39 |
| | oh, right. Well, we could extend that to UsePlanarBuffer too if we wanted, but frankly, I'm happy that setting UsePlanarBuffer only has effect on the next opening. | 16:12.35 |
| ray_laptop | In devices/gdevbit.c it allows for changing bits per component using -dGrayValues, if the geometry changes, it call gs_closedevice to force re-opening | 16:12.36 |
| Robin_Watts | I think the sole purpose of UsePlanarBuffer was for Peter to test the planar device with ppmraw. | 16:13.02 |
| ray_laptop | so the gdev_prn_put_params_planar could also close the device, right (if planar or not changed) | 16:14.04 |
| Robin_Watts | ray_laptop: Just to be clear... a pad value of "64" means "ensure that the width is padded to a multiple of 64" right? | 16:14.13 |
| | ray_laptop: It could, but I don't see the point in changing the code now. Cos I'm lazy. | 16:14.34 |
| ray_laptop | Robin_Watts: no, pad of 64 means make sure there are at least 64 extra bytes following what is required for the width | 16:14.49 |
| Robin_Watts | ray_laptop: Oh. | 16:15.07 |
| ray_laptop | eg. a pad of 3 means I want 3 extra bytes, but align_mod may provide even more pad | 16:15.31 |
| Robin_Watts | can those bytes include the following line ? | 16:15.40 |
| ray_laptop | Robin_Watts: no | 16:15.49 |
| Robin_Watts | Gotcha,# | 16:15.54 |
| ray_laptop | I see where you might have been going -- as long as we have enough pad on the last line, then as long as it can contain "garbage", we *could* overlap. But I think it is better to have the pad for each line not overlap | 16:19.11 |
| Robin_Watts | I agree. | 16:19.29 |
| | ray_laptop: Can we assume that the align_mod will always be a power of 2? | 16:19.51 |
| | if so, I'd like to use dev->log2_align_mod rather than dev->align_mod as we then use shifts, not divides. | 16:20.22 |
| ray_laptop | Robin_Watts: OK. It also makes sure that someone doesn't mess up and set it to a value that is not a power of 2 | 16:22.27 |
| | I don't see any reason for someone to want alignment that is not a power of 2 | 16:24.57 |
| | I recall one CPU that had a 60 bit word | 16:25.27 |
| | and B1700 used 36 bit word in FORTRAN, and COBOL had a different word size -- the memory controller did the pack/unpack and the micro code changed per process depending on the language | 16:28.07 |
| henrys | ray_laptop: we'll get a consultant to do the 60 bit port if it ever comes about. | 16:28.10 |
| Robin_Watts | I've worked with SIMD stuff that had 36 bits in registers, but I think that kind of thing is rarer than rocking horses these days. | 16:28.12 |
| ray_laptop | They still sell newrocking horses in stores :-) but other than ebay, I don't think you'll find such a beast, and then it'll be used | 16:29.36 |
| Robin_Watts | ray_laptop: I was being polite. the proper phrase is "rarer than rocking horse shit" | 16:30.08 |
| henrys | mvrhel_laptop: are you good with marti's changes, maybe you said something and I missed it? | 16:31.08 |
| mvrhel_laptop | henrys: oh sorry. I am good with it. | 16:31.31 |
| ray_laptop | I almost forgot. CalComp had built their own CPU that was 9 bit and had an 18 bit address range | 16:31.43 |
| henrys | okay I'll get that going mvrhel_laptop thanks | 16:31.50 |
| ray_laptop | They did this because the read 9 bits from 9 track mag tape. That way they could use the parity bit as data :-/ | 16:32.54 |
| | circa 1960, iirc | 16:33.18 |
| Gigs- | Robin_Watts: can you give me a hint where to start if I wanted to make a mutool to alter tint transforms? Don't need spoonfeeding but a little direction as to what bit of the APIs I should be looking at would help. | 16:33.29 |
| henrys | bbiab | 16:33.32 |
| Robin_Watts | Gigs-: Crumbs. | 16:33.57 |
| | Can you be specific about what you want to do? | 16:34.10 |
| Gigs- | loop through every object, identify tint transforms and alter the translation streams | 16:34.35 |
| Robin_Watts | Ok, so you can do pdf_open_document to get a handle on the document. | 16:35.01 |
| ray_laptop | Robin_Watts: since you are almost done for the day, to you want me to take a whack at the new (I agree better) approach ? Or do you have some partially done work you want me to pick up ? | 16:36.25 |
| Robin_Watts | pdf_xref_len(doc) then gives you the maximum number of objects in the document. | 16:36.27 |
| | ray_laptop: I only have a simple amount of work done on it. | 16:36.59 |
| | I'll bash on it for a few minutes more and then upload it to my repo so you can look at it if you want. | 16:37.23 |
| ray_laptop | Robin_Watts: OK. | 16:37.33 |
| Robin_Watts | Gigs-: So you can then do pdf_load_object(doc, num, gen); (and just assume gen is 0 - life is too short otherwise). | 16:37.55 |
| | That'll get you a pdf_obj * for each object in the file. | 16:38.09 |
| Gigs- | yeah I have parsed the xrefs before and we had almost no multigens | 16:38.41 |
| Robin_Watts | You can then do a pdf_get_dicts(object, "Type"); to get the /Type entry from the object (or NULL if it's not a dict). | 16:39.00 |
| Gigs- | everything's pointers so if you change it it changes what the write function writes out? | 16:40.07 |
| | I mean it's all by ref right | 16:40.14 |
| Robin_Watts | actually... you probably want to do something like if (!strcmp("TintTransform", pdf_to_name(pdf_dict_gets(object, "Type"))) { ... } | 16:40.54 |
| | and in there you can poke around to change stuff. | 16:41.21 |
| | yes, it's all by ref. | 16:41.27 |
| Gigs- | they aren't named like that | 16:41.30 |
| | I'll have to find color space definitions and follow the refs | 16:41.42 |
| Robin_Watts | Gigs: Well, however they are named. | 16:41.46 |
| Gigs- | yep | 16:41.53 |
| | well that gives me a place to start, thanks | 16:41.59 |
| Robin_Watts | np. | 16:42.04 |
| ray_laptop | Aren't tint transforms just functions that are the 4th element of the a sep colorspace (which is an array that has /Separation as the first element) ? | 16:44.24 |
| Gigs- | yeah, but usually by ref to another object | 16:44.41 |
| | also deviceN | 16:45.00 |
| | so I'll have to look for objects that are arrays that start with /Separation or /DeviceN, grab the 4th element reference, then go to that object and alter the function | 16:45.37 |
| ray_laptop | Gigs-: yes. But my point is there are no dicts with TintTransform in them, right ? | 16:45.50 |
| Gigs- | not that I'm aware of | 16:45.57 |
| | I just needed a hint of where to start, I know looking at dicts won't help | 16:46.50 |
| Robin_Watts | ray_laptop: Yeah, my specific example above was wrong. | 16:48.06 |
| ray_laptop | Gigs-: OK. Most colorspace arrays can be found in the resource chain, but images often have explicit colorspace arrays | 16:48.41 |
| Gigs- | are you saying inside of streams or something? | 16:49.44 |
| | I think I only need to worry about standalone colorspaces in my world | 16:49.57 |
| | usually they are an object that contains a single array | 16:50.34 |
| | never seen them any other way | 16:50.39 |
| | if it all goes belly up I can always beg miles or whoever your money guy is these days for an NRE | 16:51.59 |
| ray_laptop | Gigs-: no, ColorSpace (or CS) are elements of image dicts. There can be colorspace set by JPX in the stream, but they won't ever be separation colors | 16:52.32 |
| Robin_Watts | An alternative way to work would be to hook the interpreter to call your routine whenever it met a tint transform. | 16:53.05 |
| | and your routine could rewrite it in place. | 16:53.13 |
| | Then you'd open the document and run through rendering each page, discard the renders, and store the file back at the end. | 16:53.40 |
| Gigs- | where would that be in the code, in the open call? | 16:53.40 |
| | oh so actually run the pdf | 16:53.57 |
| Robin_Watts | Yeah. | 16:54.03 |
| | That would require actually changing the interpreter code a bit. | 16:54.12 |
| ray_laptop | and if you render at a low res, it'll be faster | 16:54.19 |
| Gigs- | I was looking for something more like the clean tool where I could keep it high level | 16:54.20 |
| Robin_Watts | I understand. | 16:55.02 |
| Gigs- | ray if anyone used JPX in a prepress file they deserve a trout | 16:55.10 |
| ray_laptop | Gigs-: agreed | 16:55.19 |
| Robin_Watts | The risk you run with your approach is that it's undirected; you might get false positives I guess. | 16:55.29 |
| | but the effort of having to specifically walk the resource tree is more than you want to do I'd guess. | 16:55.51 |
| ray_laptop | Robin_Watts: not too likely since the first array element is one of two names, and the array length is known and the element that is a tint transform must be a function | 16:56.46 |
| Gigs- | if you think that's risky you'd die if you saw my separation renamer code :P | 16:56.57 |
| Robin_Watts | ray_laptop: Yeah, unlikely I'll grant you. | 16:57.01 |
| Gigs- | it was basically a global find and replace of the string anwhere in the file | 16:58.31 |
| ray_laptop | Robin_Watts: I agree that finding all the Resource ColorSpace in all of the dicts might be a bit tedious. Does the parser return the object type ? (arraytype) | 16:58.32 |
| Robin_Watts | ray_laptop: You can call pdf_is_array(obj); | 16:58.59 |
| | or you just treat it as an array, and you get NULL values back. | 16:59.21 |
| | so you can do something like char *name = pdf_to_name(pdf_array_index(object, 1)); if (!strcmp(name, ...) || !strcmp(name, ...)) { ... } | 17:00.20 |
| | or something like that. | 17:00.29 |
| ray_laptop | array index 1 is the second element, right ? | 17:00.50 |
| Robin_Watts | as I say, "something like that" :) | 17:01.01 |
| ray_laptop | Robin_Watts: granted | 17:01.09 |
| Robin_Watts | my point is that you don't need to check the types all the time, and check for NULLs etc. | 17:01.33 |
| ray_laptop | so pdf_to_name will always return a string ? If it returns NULL, you don't want to strcmp it | 17:02.55 |
| | but maybe that was part of the "something like that" | 17:03.34 |
| Robin_Watts | pdf_to_name(NULL)="" | 17:04.03 |
| | specifically to avoid you having to check for NULL all the time. | 17:04.18 |
| ray_laptop | Robin_Watts: that's what I was asking. That seems like a good thing | 17:05.16 |
| Gigs- | idiot proofing, don't worry I'll find a way to break it :) | 17:06.29 |
| Robin_Watts | Gigs-: It's been developed by some of the best idiots we could fine. | 17:13.51 |
| | find. | 17:13.53 |
| ray_laptop | mvrhel_laptop: Did you see my comment about the icc logic throwing -1 instead of gs_error_VMerror when allocations fail ? | 17:16.41 |
| | Did you have a reason to always use -1 ? | 17:17.01 |
| | mvrhel_laptop: BTW, there are a *LOT* of places in the gsicc_manage that don't check for allocs returning NULL. | 17:28.02 |
| | mvrhel_laptop: also, there are a couple of void functions that do allocs that have no way to bubble the error up (eg., gsicc_add_cs) | 17:54.02 |
| | bbiab | 18:13.26 |
| Robin_Watts | ray_laptop: for the logs: There are 2 commits on robin/master | 18:27.05 |
| | The first one runs with no changes on the cluster. The second gives some differences in psdcmyk. I need to look at why. | 18:27.43 |
| | but only in 53/18893 files, so it's got to be a problem with planar + pattern clist or something. | 18:28.19 |
| | It's to do with the pattern accumulator/clipper etc not getting num_planes etc from the original devices. | 18:58.14 |
| | But I really have to go now. | 18:58.19 |
| mvrhel_laptop | ray_laptop: I thought I fixed all the error checking in that part of the code (I did a fix for a lot of those awhile ago) but I obviously missed some | 19:21.23 |
| ray_laptop | mvrhel_laptop: I'll post the changes on my repo for you to review. | 19:21.48 |
| mvrhel_laptop | ok | 19:21.53 |
| ray_laptop | I want to find the ones that are "void" that do allocations, but those can be separate | 19:22.33 |
| | I also should change the comments above functions that say "returns -1 on error" to "-1 or VMerror" | 19:24.06 |
| mvrhel_laptop | I thought I got all of those | 19:24.11 |
| | but I guess not | 19:24.19 |
| | ray_laptop: so did the one fix that I did for comparing ICC spaces fix the issue for Len? | 19:24.50 |
| | oh I guess so | 19:25.09 |
| | there is his email | 19:25.13 |
| ray_laptop | mvrhel_laptop: yes. Thanks. I'll have a look at his other question in a bit | 19:27.26 |
| | the git repo is updated. The diff should be easiest to look at: http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=91a23ad52404ae59a3e5ec8315529d3e693b876c | 19:28.42 |
| | the fact that icc allocation failures threw -1 keeps them from getting an error page printed (I think) we just die with FatalError | 19:30.18 |
| | but I need to investigate that to see if I can get an error page out of their sim, but it is now a lower priority | 19:31.10 |
| | bbiaw (yeah, I know I just got here :-) ) | 19:31.41 |
| mvrhel_laptop | ray_laptop: diffs all look good. | 20:04.20 |
| | sorry you had to clean up my mess :( | 20:04.42 |
| JakeSays | so i'm trying to write a function to count the number of image masks in a pdf. when i 'print' the pdf i get 4 image masks reported to my fill_image_mask function, but when i just iterate over the objects in the pdf looking for ones that have a type of "Image" i get 87. is there a way to identify those masks without having to run the pdf? | 22:09.44 |
| ray_laptop | mvrhel_laptop: np. I was just doing it while waiting for Robin_Watts to push his changes | 22:19.01 |
| | mvrhel_laptop: I pushed the changes. Thanks for the quick review | 22:49.47 |
| JakeSays | lol. so yeah 87 is correct. the stupid pdf had 30 pages in it. | 23:05.19 |
| JakeSays | facepalms | 23:05.24 |
| mvrhel_laptop | ray_laptop: ok thanks | 23:06.20 |
| ray_laptop | mvrhel_laptop: something strange. I just ran the AIX361DC_Save.pdf on 9.06 and saw the 890Mb allocation with the task manager, but when I run the HEAD (with your patch), I see the same allocation during parsing. | 23:11.18 |
| | the 9.06 hovers around 230M during rendering, but HEAD is at around 550M :-/ | 23:12.04 |
| | but, the patch allows me to print with cust 532's code | 23:12.45 |
| | I have to run (yet another) errand. bbiab | 23:13.29 |
| mvrhel_laptop | ray_laptop: there are a lot of diffs between 9.06 and head. most notably is the proper handling of color space changes for non-isolated groups | 23:33.27 |
| | and knockout groups | 23:33.33 |
| | this could cause the allocation of some buffers that did not exist in 9.06 | 23:33.50 |
| | especially for this file | 23:35.28 |
| Robin_Watts | ray_laptop: Are you waiting for me? | 23:55.22 |
| | I have 2 sets of changes up there, but the second one doesn't quite work yet, and I haven't made everything use them yet. they are a work in progress. | 23:55.58 |
| | Forward 1 day (to 2013/11/02)>>> | |
IRC Logs