| | <<<Back 1 day (to 2013/10/17) | 2013/10/18 |
| ray_laptop | marcosw: Might be this: http://www.turnkeylinux.org/forum/support/20120308/upgrade-rsa-key-changed-and-ssh-issue Also see: https://forums.aws.amazon.com/thread.jspa?threadID=25149# | 00:04.44 |
| | As long as we don't reboot, we're probably OK :-) | 00:05.45 |
| | I think I found the resolution dependent issue with bug 694714. The clip path outer box was 1 pixel past the dev->height | 00:07.29 |
| marcosw | the reboot didn't change the host keys this time. | 00:29.32 |
| | something is still terribly wrong with casper. I'm going to take it down and see what's up. | 00:39.22 |
| ray_laptop | marcosw: I saw your email. Bummer. I see that you have a gs regression creeping along. Does this mean that I shouldn't try a regression run ? | 04:12.46 |
| | well, I guess all it might do is abort. Going to give it a try... | 04:21.49 |
| | marcosw: did you do something that killed peeves as a regression machine ? peeved is up and they are both on the same subnet in my office. peeves itself is up and healthy. Did the clusterpull die on some machines | 04:33.17 |
| | strange. I watch peeves running and see the clusterpull.sh run occasionally, but the touch of machine.up isn't working -- the time is locked at 4:46 even though I see it running. | 05:06.17 |
| | ahh... somehow the known_hosts on peeves in ~marcos/.ssh got updated. When I manually ran the "touch up" ssh line from clusterpull (as marcos) it prompted me to allow the host key to be updated. | 05:11.40 |
| | then it worked and the time on casper for peeves.up looks OK. | 05:12.16 |
| | marcosw: the other machines that are marked "DOWN" may have a similar problem. | 05:13.23 |
| | time to get ready for bed | 05:14.49 |
| kens | For the logs, one for the MuPDF developers | 07:21.13 |
| | http://stackoverflow.com/questions/19429465/disable-jdvu-compiling-mupdf | 07:21.13 |
| sebras-work | kens: ehm.. but mupdf doesn't support djvu..? | 07:58.46 |
| | kens: my guestt is that he's using https://code.google.com/p/ebookdroid/ | 07:59.39 |
| | guess... | 07:59.43 |
| kens | sebras-work : I wasn't sure about the DjVu comment, I certainly know MuPDF doesn't support it. | 08:01.06 |
| | I was thinking more of the 'compiling the JNI' stuff | 08:01.26 |
| sebras-work | kens: it seems as if he wants to disable djvu and thereby reduce the size of the .so-files in the .apk. so this makes me think that he's using ebookdroid (which combines djvu with mupdf) rather than our git repo for compiling. | 08:07.08 |
| | our... your! :) | 08:07.15 |
| kens | Hmm, well that's possible certainly | 08:13.01 |
| | Still probably best if someone other than me replies to him :-) | 08:13.13 |
| sebras-work | kens: and I have no account over at SO | 08:29.07 |
| kens | sebras-work : tor Robin_Watts and paul all do | 08:29.23 |
| sebras-work | ...because then I feel compelled to answer. ;) | 08:29.33 |
| Robin_Watts | morning | 08:40.10 |
| kens | morning Robin_Watts | 08:40.24 |
| Robin_Watts | I will have a look at the stackoverflow question. | 08:40.38 |
| kens | Thanks | 08:40.44 |
| Robin_Watts | bugger. I've forgotten my stackoverflow login details :( | 08:47.15 |
| kens | I can post an answer for you if you want | 08:47.36 |
| | I must do something about my login too, now my credentials are going to be unsupported | 08:48.41 |
| Robin_Watts | tries to remember how the clist calculates the bandheight it uses. | 13:12.55 |
| | I think it does something clever by taking the total size available to it and dividing it up by the number of threads it's using or something. | 13:13.25 |
| | With this process_page stuff, if we need additional buffering per band, that should be allowed for in that calculation too, I think. | 13:14.17 |
| | but the buffering may itself depend on the bandheight, so it's not trivial :( | 13:14.41 |
| ray_laptop | Robin_Watts: I had considered incorporating num_rendering_threads_requested to make sure there are enough bands, but it doesn't currently. The band_height is set in clist_init_data. If not fixed is uses what is returned from gdev_mem_max_height | 14:25.04 |
| Robin_Watts | ray_laptop: Ah, morning. | 14:25.25 |
| ray_laptop | good mornng, Robin_Watts (and everyone else) | 14:25.51 |
| Robin_Watts | I'd decided to ignore the process_page stuff in the band height calculations. | 14:26.01 |
| | as 1) it's too complex, and 2) such buffer calculations are not included when being done in the device currently. | 14:26.33 |
| ray_laptop | Robin_Watts: you mean the business of setting the band to a helpful number of lines ? | 14:27.07 |
| Robin_Watts | ray_laptop: I mean the allocation of any per thread buffers that process_fn may need. | 14:27.41 |
| | For instance, with the 'fastpng' device I am doing here, I am doing the zlib compression on the threads. | 14:28.18 |
| | which means each thread needs an output buffer. | 14:28.31 |
| ray_laptop | right | 14:28.43 |
| Robin_Watts | In an ideal world, we might try to allocate that out of maxBitmap too. | 14:29.04 |
| | but I think that's just too much work. | 14:29.11 |
| ray_laptop | agreed | 14:29.20 |
| | It is mentioned that multiple threads will *each* consume memory, including the buffer, so also having a destination buffer per thread seems fine. | 14:38.50 |
| | multiple core processors usually go along with a fair amount of memory | 14:39.16 |
| henrys | you can expense a standing desk ⦠just sayin' http://www.bbc.co.uk/news/magazine-24532996 | 14:56.41 |
| ray_laptop | Robin_Watts: or anyone: Can you review the bug 694714 patch that's on my repo ? | 15:08.51 |
| Robin_Watts | looking now. | 15:09.00 |
| ray_laptop | Robin_Watts: I mention you because marcos had assigned it to you until I snagged it. | 15:09.18 |
| Robin_Watts | ray_laptop: Yeah, looks like a sane change to me. | 15:10.07 |
| ray_laptop | Robin_Watts: thanks. I looked at other cpath_outer_box uses and there are some others that I was going to "fix" similarly where the box doesn't get intersected with some other box | 15:10.49 |
| | But I wanted the bug fix to be a separate commit, first | 15:11.08 |
| Robin_Watts | ok. | 15:11.14 |
| | ray_laptop: Random thing... in gxclimag.c line 974 | 15:18.25 |
| | If we failed to allocate a block, free the block we just failed to allocate ? | 15:19.13 |
| ray_laptop | Robin_Watts: yeah, superfluous, but harmless since freeing a pointer that is NULL is a no-op (and relied on many places). | 15:22.33 |
| Robin_Watts | ray_laptop: Right. I was just wondering if it was maybe supposed to be freeing something else? | 15:22.59 |
| ray_laptop | Robin_Watts: it probably was supposed to free the 'pie' | 15:23.13 |
| Robin_Watts | i.e. often you see: allocate_a; if (failed) return; allocate(b); if (failed) {free(a); return;} | 15:23.31 |
| | right. | 15:23.36 |
| ray_laptop | allocated at line 673 | 15:23.38 |
| Robin_Watts | That would make sense. | 15:24.23 |
| ray_laptop | If it does free pie, then it should probably set *pinfo = NULL as well to avoid having a pointer to freed memory laying around, even though with an error return, that shouldn't be used. | 15:24.51 |
| | I have to run get coffee. bbiab (5 min) | 15:25.28 |
| | Robin_Watts: since you found it, do you want to go ahead and fix it, or should I ? | 15:34.01 |
| Robin_Watts | ray_laptop: I have a fix here. I'll stick it on my repo for you to review later, and I'll test it on the cluster with the process_page stuff. | 15:34.33 |
| ray_laptop | Robin_Watts: OK. Please set the *pinfo as well, then. | 15:35.02 |
| Robin_Watts | ray_laptop: Have done. | 15:35.09 |
| ray_laptop | great, thanks | 15:35.15 |
| Robin_Watts | I also added *pinfo = NULL to the bottom (error case) exit from the function. | 15:35.27 |
| ray_laptop | Robin_Watts: do you mean the "use_default:" area ? | 15:37.08 |
| Robin_Watts | yes., | 15:37.19 |
| ray_laptop | if so, then I agree, but gx_default_begin_typed_image will set it to something else anyway | 15:37.48 |
| | but as a style, I prefer doing it as you suggest | 15:38.23 |
| | suggest / have done | 15:38.35 |
| henrys | chrisl:about the color index gx_device type is broken into everywhere. You know I think we are too quick to blame Peter for some of our problems - he intended the device structure to be opaque, everybody "breaks" into it and then we blame him for bugs for peculiar interactions in the code. | 15:44.24 |
| | s/for bugs for/for bugs and | 15:45.45 |
| sebras-hotel | http://bugs.ghostscript.com/show_bug.cgi?id=693228 -- who is Michael..?! | 15:47.19 |
| | a new contributor it seems, but unknown to me. :) | 15:49.38 |
| | unfortunately I can't test his patch until I'm back in .se in November, so if someone feels like doing the test then feel free. | 15:50.08 |
| Robin_Watts | Michael = Micha` | 15:50.41 |
| Gigs- | ray_laptop: thanks so much for fixing that segfault quickly... I'll deploy today probably | 15:53.28 |
| sebras-hotel | Robin_Watts: oh. | 16:00.38 |
| ray_laptop | Gigs-: since it also happened on windows, it was easy to work on. I also have linux, but the tools aren't quite as nice (usually) | 16:02.22 |
| | henrys: I'm not sure that LPD wanted the gx_device to be opaque, but I agree that places that assume a a gx_device * is "really" a gx_device_some_other_dev * is a problem and not supposed to be done outside of procs that device has | 16:05.29 |
| | sorry about the *'s causing shouting (chatzilla shows it as bold) | 16:05.59 |
| henrys | ray_laptop:he always used an incomplete type when he wanted that - certainly the languages should not be accessing the fields in gx_device directly. | 16:09.14 |
| ray_laptop | henrys: for the parser layers, probably so. I was thinking the device type. | 16:12.14 |
| | generally he'd provide a get_ or set_ fn in the graphics lib for the parsers to use. I was thinking about inside the graphics lib | 16:13.10 |
| | oops. I have to run. bbiab | 16:14.41 |
| Robin_Watts | paulgardiner: How's .it ? | 16:15.56 |
| paulgardiner | Lovely hotel with great views. Should have heeded your advice on italian taxi drivers though | 16:17.13 |
| Robin_Watts | oh. expensive? | 16:17.26 |
| chrisl | henrys: sorry, was on the phone. The best I can suggest is to create a bug, and we'll pass it round so everyone can review areas of the code for which they are responsible. Although personally, I don't think it's such a big deal...... | 16:18.51 |
| paulgardiner | After turning down the 120euro direct trip to sorrento, and requesting the 4euro one to the local train station, driver absolutely assured us we were too late for the train to sorrento. | 16:19.44 |
| Robin_Watts | To which the answer is "just take me to the &*%$! station, guiseppe" | 16:20.46 |
| paulgardiner | Yeah, if you are sure that the claim is untrue. | 16:21.35 |
| | Mind you, the taxi trip was quite an experience. It will be a lasting memory, so worth something for that alone. :-) | 16:23.32 |
| henrys | chrisl I think it is too widespread to be dealt with safely | 16:26.02 |
| Robin_Watts | henrys: The device interface in gs is absolutely not intended to be a private one. | 16:26.58 |
| | It's designed for public consumption - how else are people supposed to write devices? | 16:27.29 |
| henrys | I think you are confusing opaque types and privacy. I want a routine to access the resolution of the device, not ores = dev->Resolution[0] | 16:28.35 |
| Robin_Watts | You want an accessor function, in other words. | 16:29.14 |
| henrys | I don't need to know how the resolution is stored. | 16:29.15 |
| Robin_Watts | and yes, I'd concur that that is a nicer scheme. However in the C world that means a function call on every access (or more wonderful macros!). | 16:29.59 |
| | So I can understand why that isn't used in all cases. | 16:30.18 |
| chrisl | It's often the problem with doing these things "properly" that APIs don't get redesigned every time the data structure changes - 'cause that's time and effort which often isn't available | 16:34.10 |
| | And I really don't nested accessor functions, where you end up with things like: gs_device_x_resolution(gs_device_resolution(gs_currentdevice(pgs))) | 16:41.41 |
| Robin_Watts | zlib, how do I love thee, let me count the ways... | 16:43.44 |
| Gigs- | one danger with that type of thing is that if it's more than just an accessor, it can hide serious performance sinks | 16:43.48 |
| ray_laptop | henrys: there is a gs_deviceinitialmatrix and a gx_device_set_resolution but no gx_device_get_resolution. You could add one :-) | 16:47.44 |
| henrys | the resolution is easily derived from initialmatrix | 16:48.57 |
| | I guess somebody could change it though... | 16:49.27 |
| ray_laptop | henrys: right. There doesn't seem to be a call to get the current res | 16:50.25 |
| henrys | ray_laptop: right | 16:51.14 |
| chrisl | Presumably the original intention was that the resolution would only accessed via get_params() | 16:51.28 |
| ray_laptop | chrisl: right, but that's a bit slow if needed with any frequency | 16:52.15 |
| chrisl | ray_laptop: yes, the point I was making above is that APIs often get redesigned in the light of requirements outside the original design - usually due to resource constraints | 16:53.15 |
| | erm " APIs often don't get redesigned" | 16:53.36 |
| ray_laptop | chrisl: well, the gs graphics lib "api" (calling it that is generous) never really got a design -- just an evolution | 16:54.13 |
| chrisl | ray_laptop: henrys's point is we should be sticking to the graphics lib API | 16:55.03 |
| ray_laptop | chrisl: as documented in lib.htm ? | 16:55.46 |
| chrisl | Personally, I think it's almost inevitable that APIs suffer like this, unless you periodically take the hit of redesigning them. | 16:56.14 |
| | ray_laptop: I'd think "as would be documented in an up to date lib.htm"! | 16:56.53 |
| Robin_Watts | chrisl: Yes. It's typical of software engineering that one lurches from crisis to crisis doing the short term fixes without having time to look back and say "well, actually, if we rework all of this slightly it'd be neater" | 16:58.02 |
| Gigs- | I've found active resistance to refactoring in a lot of projects. | 16:59.08 |
| chrisl | Robin_Watts: exactly, yes. And it's almost impossible to make a business case to spend a lot of effort redesigning something that apparently "works" | 16:59.24 |
| Gigs- | "Well, thanks for the patch, but you touched like ... 10 files and it doesn't actually fix anything" | 16:59.24 |
| | the fear of refactoring is a downward spiral, because the code gets more and more fragile, and the reluctance to refactor increases | 17:01.17 |
| Robin_Watts | I'd really like to see us undertake a major cleanup in gs at some stage - perhaps when going to v10. Remove all the historical crap from the device interface. static_procs, color mapping etc. | 17:04.50 |
| ray_laptop | Gigs-: well, with our cluster regression testing, at least the fear of breaking something is greatly reduced | 17:07.06 |
| Gigs- | and you have me running tiffsep on a massive number of files of mixed origin for you hehe | 17:07.37 |
| ray_laptop | Gigs-: yes, thanks for that. It would be nice to have that done a bit before we release | 17:08.46 |
| | Gigs-: but anytime is better than not running it | 17:09.06 |
| Gigs- | for a while I was running releases but for the last 8 months or so I've been mostly keeping up with git | 17:09.10 |
| ray_laptop | Gigs-: awesome ! | 17:09.23 |
| | hi, marcosw | 17:12.05 |
| | thanks for sorting out the cluster. Looks like it's running fine. | 17:12.22 |
| Robin_Watts | ray_laptop: Woo Hoo! process_page is tigering. | 17:13.23 |
| | Both with and without NumRenderingThreads! | 17:14.07 |
| ray_laptop | Robin_Watts: great. Is this with png flate in threads ? | 17:14.08 |
| Robin_Watts | yes. | 17:14.13 |
| ray_laptop | Robin_Watts: do you have a decent multi-core processor to try it on ? | 17:14.33 |
| Robin_Watts | ray_laptop: Core 2 Quad | 17:14.50 |
| ray_laptop | if not, peeves (if there isn't a regression running) wouldn't be bad. It's an i7 | 17:15.13 |
| | or peeved (dual Xeon Quad core) | 17:15.29 |
| | but a Core 2 Quad should be fine (that's the same as in i7, I think) | 17:16.27 |
| Robin_Watts | I thought i7 had more cores? | 17:16.46 |
| ray_laptop | An i7 has (AFAIK) 4 cores, each with hyperthreading so in theory, 8 threads work (mostly) | 17:17.29 |
| Robin_Watts | Just about to try some timings - waiting for a release build. | 17:18.04 |
| | OK, so 600dpi with png16m is 3.3s or so to give a 493k file. | 17:19.54 |
| | fpng with no threading at 600dpi is 1.9s | 17:20.33 |
| | for a 523k file. | 17:20.51 |
| | 2 threads = 1.3s | 17:21.34 |
| | for the same 523k file. | 17:21.48 |
| | 3 threads = 0.88s | 17:22.11 |
| ray_laptop | Robin_Watts: what is fpng ? | 17:22.27 |
| Robin_Watts | 4 threads = 0.77s | 17:22.38 |
| | fpng = my new png device that uses process_page, and doesn't touch libpng | 17:22.58 |
| | We can't drive libpng in the way we need, so I lifted the png producing code from mupdf. | 17:23.34 |
| ray_laptop | Robin_Watts: fpng doesn't compress as well -- is it doing the predictor as well as the flate ? | 17:23.58 |
| Robin_Watts | It is. | 17:24.08 |
| | It does the simple 'sub' predictor. | 17:24.15 |
| ray_laptop | I thought paeth was usually used ? | 17:24.32 |
| Robin_Watts | the flushing on each band hurts the compression. | 17:24.37 |
| | ray_laptop: Not in mupdf :) | 17:24.42 |
| ray_laptop | Robin_Watts: what band size are you using? | 17:25.10 |
| Robin_Watts | -dMaxBitmap=10000 | 17:25.24 |
| ray_laptop | setting the BandHeight to 1/n of a page where n is NumRenderingThreads would be interesting | 17:25.40 |
| Robin_Watts | -dBandHeight=something ? | 17:26.00 |
| ray_laptop | Robin_Watts: yes | 17:26.42 |
| | The default is 30 bands | 17:26.54 |
| | -Z: on a debug build tells you | 17:27.11 |
| Robin_Watts | OK, with a bandheight of 1755 (so 4 bands)... | 17:29.02 |
| ray_laptop | even cutting down to 8 or 12 or 16 bands would probably help the compression. -dBandHeight=825 -dBandHeight=550 -dBandHeight=413 | 17:29.07 |
| Robin_Watts | 0.917s | 17:29.23 |
| ray_laptop | Robin_Watts: why 1755 ? 6600 / 4 = 1650 | 17:29.46 |
| Robin_Watts | Tiger is 4958x7017 at 600dpi | 17:30.12 |
| ray_laptop | you must be defaulting to a4 | 17:30.24 |
| Robin_Watts | I'd hope so :) | 17:30.28 |
| | That gives a 520k tiger. | 17:31.06 |
| | but I think this proves that multithreading helps :) | 17:31.31 |
| ray_laptop | how come you brits are so confused. You use inches and feet but 11.7 inch long paper (instead of 11 inch) ??? | 17:31.37 |
| | Robin_Watts: I'm surprised that the performance with 4 bands is not as good as with 30 | 17:32.08 |
| Robin_Watts | ray_laptop: yeah. | 17:32.35 |
| ray_laptop | and it seems like doing 30 'resets' of flate really doesn't hurt | 17:32.47 |
| Robin_Watts | Let me put a patch up for you to 'ew!' at. | 17:32.53 |
| ray_laptop | hurt the compression much | 17:32.57 |
| Robin_Watts | The resets themselves cost <8 bytes. | 17:33.14 |
| ray_laptop | Robin_Watts: I'll grab a fresh barf bag. Usually reserved for looking at customer's code ;-) | 17:33.23 |
| Robin_Watts | but the fact that each block can't look back at the previous band for matches will hurt a bit. | 17:33.45 |
| | The paeth predictor involves looking up as well as left, right ? | 17:34.13 |
| | oh, the predictor is sent per line, so we'd be OK. | 17:34.36 |
| | ray_laptop: 3 commits on robin/master for your friday afternoon enjoyment :) | 17:39.44 |
| ray_laptop | Robin_Watts: OK. Thanks. | 17:43.27 |
| | Robin_Watts: go ahead with the gxclimag.c change. No further review needed. | 17:44.55 |
| Robin_Watts | I'll just do a quick clusterpush. Not that I've been bitten before by such changes or anything :) | 17:45.36 |
| ray_laptop | Robin_Watts: Just the post commit clusterpush should be plenty for that one | 17:47.34 |
| Robin_Watts | ray_laptop: I'd prefer to avoid the history containing "here's a stupid mistake" followed by "here's my fix for the stupid mistake". | 17:48.08 |
| ray_laptop | Robin_Watts: true. That's why we do commit --amend on the master repo, isn't it ;-) | 17:48.47 |
| Robin_Watts | :) | 17:49.03 |
| ray_laptop | Robin_Watts: so, "options": The *_arg elements vs. The *arg in the various _fn calls. How do those relate ? | 17:58.52 |
| Robin_Watts | In options you have blah_fn and blah_arg | 17:59.23 |
| ray_laptop | right | 17:59.30 |
| Robin_Watts | for 4 different values of blah :) | 17:59.31 |
| | The blah_arg is always supplied as the first argument to blah_fn | 17:59.46 |
| ray_laptop | yes. but each blah_fn gets called with a void (* arg | 18:00.10 |
| ray_laptop | didn't type fast enough | 18:00.24 |
| | So, how do the blah_arg values get set ? | 18:01.07 |
| Robin_Watts | ray_laptop: The caller of process_page passes in dev and &options | 18:01.35 |
| | so the caller fills in all the functions and the args. | 18:01.54 |
| ray_laptop | it seems that passing the gx_process_page_options_t *options struct would allow for that | 18:01.55 |
| Robin_Watts | That doesn't play nicely with chaining. | 18:02.21 |
| | or as nicely. | 18:02.31 |
| | Suppose I want to add the downscaler into fpng. | 18:02.49 |
| | I'd call downscaler_process_page, and that would hook some of the fns | 18:03.30 |
| ray_laptop | so that when, for example the init_buffer wants to allocate a struct that will be used by the process_fn, it puts it in the *buffer ? | 18:03.34 |
| | I'm thinking about the process "state" | 18:04.23 |
| | or is there no 'state' allowed between one buffer and the next ? | 18:04.59 |
| Robin_Watts | init_buffer is called for each thread before the threads start up (or just once in the single threaded case). Each call returns a buffer. | 18:05.11 |
| | ray_laptop: What state could there be? | 18:05.33 |
| ray_laptop | OK, and we don't allow state between buffers ever | 18:05.35 |
| Robin_Watts | If you want to share state between the threads (I can't quite see what) then either you'd put that state in the device itself, or you'd put it in process_arg | 18:06.19 |
| ray_laptop | Robin_Watts: OK. | 18:06.56 |
| Robin_Watts | The point of the buffer stuff is that process_fn can work into those out of order, but they are delivered in order to output_fn | 18:07.08 |
| ray_laptop | So I am fine with that patch, but I'd label is 'alpha -- subject to change' until we have a chance to maybe try a few other example implementations. | 18:08.50 |
| | just to make sure that we have the hooks we want, although it seems quite flexible | 18:09.21 |
| Robin_Watts | ray_laptop: Sure. | 18:09.29 |
| | I'd like to try to push the downscaler into here, as (for the non error diffusion cases) that would benefit. | 18:10.24 |
| | In fact, even the error diffusion cases could have the downscale handled in the threads and the error diffusion done afterwards. | 18:10.57 |
| ray_laptop | Robin_Watts: for example, you assume that if a process_fn wants a certain band height, the device will hook the get_space_params based on knowing what the process_fn wants (needs) | 18:11.52 |
| Robin_Watts | Yes, I assume that. | 18:12.21 |
| ray_laptop | Robin_Watts: I'm thinking about the downscaler, obviously | 18:12.31 |
| Robin_Watts | AIUI, band height selection is done WAY before process_page is called. | 18:12.46 |
| ray_laptop | Robin_Watts: yes, it's done before we begin writing the clist | 18:13.07 |
| Robin_Watts | So the downscaler should probably provide some 'helper' functions the device can use to ensure it gets the right bandheight. | 18:13.41 |
| ray_laptop | It does mean that the device has to "understand" any band size issues for any processing it's going to have done | 18:13.56 |
| Robin_Watts | ray_laptop: Well, the process_fn *is* the device, so that's fair enough. | 18:15.18 |
| | If the device uses the downscaler, then it needs to understand the downscaler's needs too. | 18:15.37 |
| ray_laptop | Robin_Watts: sorry. Had a phone call. Yes, I agree. The 'process' is an adjunct to a particular device. | 18:31.32 |
| | we are just providing the hook for the process to be done in our threads | 18:32.04 |
| | it's sounding good. *AND* it lets us steer cust 801 away from mods in gxclthrd.c | 18:32.50 |
| Robin_Watts | ray_laptop: Indeed. | 18:33.09 |
| | ray_laptop: So, you either didn't notice, or you didn't object to the fpng device fiddling around the band device's memory :) | 18:34.01 |
| ray_laptop | Robin_Watts: I notice you have the dev as gx_device * rather than gx_device_printer * or gx_device_clist * (which it MUST be) | 18:34.20 |
| | Robin_Watts: I haven't reviewed the 3rd (fpng) patch yet | 18:34.41 |
| Robin_Watts | ray_laptop: I need to make process_page work with page mode stuff. | 18:34.44 |
| | it should work out easily enough. | 18:35.01 |
| ray_laptop | Robin_Watts: well, it *is* still a gx_device_printer * | 18:35.09 |
| | isn't it ? | 18:35.18 |
| Robin_Watts | ray_laptop: Is it? | 18:35.20 |
| | What requirement is there for it to be a printer? | 18:35.29 |
| ray_laptop | Robin_Watts: well, ... OK. | 18:36.18 |
| | So this could be a "display" device ? | 18:36.43 |
| Robin_Watts | I don't see why not. | 18:37.18 |
| | any device that you can 'get_bits' from should be fine with this. | 18:37.48 |
| ray_laptop | Robin_Watts: Not sure when the "process_page" gets called in that case, however | 18:37.51 |
| Robin_Watts | ray_laptop: How do display devices work then? | 18:38.26 |
| | They don't have a print_page entry I guess, but they must have something that says "get the bits now and display it" | 18:39.02 |
| ray_laptop | Robin_Watts: hmm... where _does_ the device's process_page get called ? | 18:39.26 |
| Robin_Watts | ray_laptop: For printers, in the printers "print_page" entry point. | 18:39.48 |
| | Old style devices call "get_bits" for each line and deal with that. | 18:40.00 |
| | New style devices call "process_page" and the data is fed to their process/output functions. | 18:40.23 |
| ray_laptop | Robin_Watts: OK, so this is something that each device *must* call, and it's hooked via a dev_proc because the prn_device may have a page buffer _or_ a clist | 18:41.27 |
| Robin_Watts | every device has to call *something* to get the data out. | 18:41.50 |
| ray_laptop | each new device, that is | 18:41.51 |
| Robin_Watts | either they can call get_bits etc, or they can call process_page | 18:42.08 |
| | yes. | 18:42.12 |
| | The default implementation of process_page will be to call get_bits and to feed that to process_fn etc. | 18:43.31 |
| ray_laptop | Robin_Watts: when/why is the default implementation used ? | 18:49.25 |
| Robin_Watts | ray_laptop: for page mode | 18:49.44 |
| ray_laptop | Robin_Watts: so why not call get_bits_rectangle ? | 18:50.02 |
| Robin_Watts | ray_laptop: yes, I mean get_bits_rectangle, sorry. | 18:50.27 |
| ray_laptop | Robin_Watts: OK. np | 18:50.39 |
| Robin_Watts | I appear to be incapable of coding paeth correctly. | 18:50.52 |
| ray_laptop | Robin_Watts: steal, err... consult, libpng ;-) | 18:51.31 |
| Robin_Watts | gs/debugbin/gswin32c.exe -dNumRenderingThreads=4 -o out.png -r600 -dBandHeight=1755 -sDEVICE=png16m gs/examples/tiger.eps | 18:51.58 |
| | ray_laptop: If you run that, do you get warnings about leaks? | 18:52.11 |
| | They don't look like leaks from my stuff. | 18:52.25 |
| ray_laptop | tries that... | 18:53.03 |
| | Robin_Watts: yes, I see 3 objects leaked per thread | 18:53.15 |
| Robin_Watts | me too. One of which is a gsiccmanage_linkcache | 18:53.36 |
| ray_laptop | They are mvrhel's AFAIK -- one is that one | 18:53.42 |
| Robin_Watts | Ok. Are they really leaked, or are they just warnings? | 18:54.12 |
| ray_laptop | since they are sequence 20, 21 and 22, I assume they are all his | 18:54.16 |
| | Robin_Watts: not really leaked, since these are warnings from the chunk allocator when it closes. | 18:54.47 |
| Robin_Watts | ok, so just noise then. | 18:55.07 |
| ray_laptop | If the allocator is the normal GC allocator, then it picks those up | 18:55.12 |
| | If we are running with a chunk allocator (as with PCL), then it'll eventually collect them. | 18:55.42 |
| Robin_Watts | threads always use the chunk allocator, right? | 18:56.03 |
| ray_laptop | I am pretty sure that there is only one of these ordinarily | 18:56.16 |
| | Robin_Watts: yes, threads each have a chunk allocator so they don't need a mutex lock per alloc/free -- only when going to the underlying (thread safe) allocator to get/return chunks | 18:57.23 |
| Robin_Watts | right, so these are fine regardless of pcl or not. | 18:57.46 |
| ray_laptop | yes, as long as they aren't "per band" or "per page" things that leak (a debug PCL build with a multipage file and a banded device would tell us when PCL closed the allocator) | 18:59.22 |
| | going to lunch now. I'll look at the fpng patch next... | 19:01.52 |
| | Robin_Watts: ahh.. the fpng commit doesn't have any .c files | 19:03.28 |
| Robin_Watts | ray_laptop: oops. Will fix that as soon as I get this working. sorry. | 19:03.44 |
| ray_laptop | Robin_Watts: it's missing gdevfpng.c -- did you forget to git add it ? | 19:03.54 |
| Robin_Watts | I did. | 19:03.59 |
| ray_laptop | OK, since it's your latest commit, you can just --amend it | 19:04.27 |
| Robin_Watts | ray_laptop: Right. Except I've broken the .c file in the meantime :) | 19:04.46 |
| ray_laptop | oops. | 19:04.53 |
| Robin_Watts | I'll try and have it working by the time you get back from lunch :) | 19:05.02 |
| ray_laptop | I'll check the logs after lunch. | 19:05.11 |
| Robin_Watts | ray_laptop: Fixed version pushed. PAETH still isn't working, but... | 19:15.14 |
| | ray_laptop: For the logs, new version with working paeth. | 20:12.04 |
| | ray_laptop: New version with working paeth up. | 21:19.19 |
| | And there is a new commit that adds a gxdso to do band height adjusting for your thoughts. | 21:19.37 |
| Micha` | Howdy ghosteam. | 21:57.34 |
| | So, I'll definitely not use Ink annotations for my PDF handwrite annotator, but I'm a bit curious about a thing. Through a rather intricate process, the appearance stream of the Ink annotation is updated to mimick the InkList; this is, as I come to understand, a good thing. However, any curve goes through a rather deep bezier-recursion before being added to the appearance stream. At the end, each segment is itsel | 22:05.16 |
| | f stored in the stream as a very short bezier curve (using the `c` operator). Is there any reason to think that a PDF reader is so bad at drawing curve that curves need to be pre-bezier'ed for it? | 22:05.16 |
| Robin_Watts | Micha`: No idea. Paul handled that stuff, and he's on holiday for a week. | 22:12.01 |
| Micha` | Robin_Watts: Thanks. I'll ask him when he's back then, no rush. | 22:19.09 |
| Amr_ | Hello, I have a question about MuPDF | 22:48.17 |
| | when I built the MuPDF for Android, it could search for Arabic words successfully using the "OpenFile()" as the Arabic pdf file stored on my local storage | 22:50.05 |
| | but when I try to open a file online by buffering it and use the "OpenBuffer()" method the search doesn't work | 22:50.57 |
| | isn't search feature works with "OpenBuffer()" method or it's a bug in my code? | 22:51.41 |
| | Robin_Watts : did you receive my question? | 22:53.14 |
| Micha` | Robin_Watts: Any opinion on http://bugs.ghostscript.com/show_bug.cgi?id=693719 ? Should MuPDF try to track a valid trailer if the one at the end points to an invalid /Root? (I'd dwell on this if there is a need to, just to get used to the library some more) | 23:03.37 |
| Robin_Watts | Amr_: It should make no difference whether you use OpenBuffer or OpenFile. | 23:32.17 |
| | Micha`: I'd need to think about it, and I've not got my mupdf hat on at the moment. | 23:33.00 |
| Micha` | No problem. Just let me know when you have thought this through, in the bug report maybe. | 23:35.03 |
| | A mupdf hat; sounds like virtual merchandising :-) | 23:35.40 |
| Robin_Watts | I have a real Ghostscript hat. | 23:35.58 |
| Micha` | Haha, awesome :-) Don't forget to put it on every time you work on gs then. | 23:36.56 |
| | Forward 1 day (to 2013/10/19)>>> | |
IRC Logs