| | <<<Back 1 day (to 2013/10/30) | 2013/10/31 |
| mvrhel_laptop | marcosw: I would think the regression machine would be just fine with the newer version but I am not going to get into with Robin_Watts about what version to go with as he is very opinionated about this | 00:03.05 |
| | I am always one to move on to the newer version | 00:03.22 |
| | and I sometimes do pay the price for this | 00:03.34 |
| Robin_Watts | I'm a version junkie when there is reason to be. | 00:03.38 |
| mvrhel_laptop | Acrobat is one that I refuse to move up on though | 00:03.48 |
| | as they took away features | 00:03.55 |
| | that I use | 00:03.58 |
| Robin_Watts | I could understand using VS2008 or VS2010 on the regression stuff. | 00:04.11 |
| | I think VS2012 or newer is asking for trouble though as they started to change more stuff (upgrading projects is much more invasive) | 00:04.42 |
| | but for command line builds it probably doesn't matter. | 00:04.54 |
| mvrhel_laptop | right | 00:15.05 |
| | now I think I can get back to mupdf again | 00:15.34 |
| | Robin_Watts: so I have printing working with the windows 8 mupdf app | 00:42.49 |
| | I have a little cleaning up to do | 00:43.02 |
| | but it was not too hard to add | 00:43.08 |
| | obviously it is doing it as rendered images but at least the app can print. there were some complaints about this feature missing | 00:43.57 |
| | and since the app is used from machines with print capability it made sense to add it | 00:44.57 |
| | need to eat dinner bbiaw | 00:45.13 |
| Robin_Watts | mvrhel_laptop: Nice one! | 00:46.11 |
| | Hmm. Looks like orig_procs is not completely initialised to zeros to start with, maybe. | 00:48.04 |
| henrys | Robin_Watts: how was the movie I don't think it gets released here until the 1st | 00:48.49 |
| | ? | 00:48.52 |
| Robin_Watts | Urm... not sure. | 00:49.05 |
| | It looked great, but I kinda got the feeling that I'd seen it all before. | 00:49.18 |
| | Harrison Ford as Morpheus, Ender as Neo. | 00:49.50 |
| | And increasingly I came to dislike Harrison Ford, but then perhaps that was the point? | 00:50.25 |
| | And the last 5 minutes of the movie seem incredibly thin. | 00:51.00 |
| | bedtime for me. | 00:56.20 |
| JakeSays | hey can mupdf be built 64bit on windows? | 01:48.21 |
| mvrhel_laptop | JakeSays: yes | 03:21.33 |
| ray_laptop | I guess I have to (re)install the 64-bit compilers on my Win system or debug on (64-bit) linux. My 7K segfaults don't happen on windows :-( | 05:19.53 |
| | time for bed. One more cluster run just to make sure that the "standard" alignment and pad still bomb | 05:31.07 |
| | hmm... I may not be aligning the address correctly :-/ | 05:48.50 |
| | bet that's it. | 05:49.35 |
| | tomorrow... | 05:49.44 |
| JakeSays | mvrhel_laptop: hey thanks | 05:55.37 |
| tor7 | Robin_Watts: ah, no, I forgot to add CMYK support to PWG output. | 09:30.42 |
| amonakov | tor7: do you have a moment to clarify a couple of things about your "gamma" patch? | 09:39.26 |
| | there seems to be a confusion about what colorspace is assumed internally | 09:40.17 |
| tor7 | amonakov: yeah, it doesn't work out of the box if you rebase it to the current master. there are several optimised routines that don't call the macro. I'm also not sure it's the right approach to take. | 09:40.22 |
| | and it won't work if you use CMYK for output | 09:40.38 |
| amonakov | freetype gives sample coverage, i.e. linear gamma | 09:40.43 |
| | but color values and bitmap data are in srgb, right? | 09:41.04 |
| tor7 | amonakov: yes, the coverage from freetype (and from our own AA) is a linear coverage value | 09:41.11 |
| amonakov | so the patch is not correct in that regard? | 09:41.24 |
| tor7 | 1.0 = fully covered, 0.5 = half covered, 0.0 = uncovered | 09:41.27 |
| | so when you blend two values, you want them to take on the colors from the background and foreground according to said coverage | 09:42.01 |
| | all color values in mupdf in rgb and grayscale space assume an sRGB gamma | 09:42.22 |
| amonakov | ah, so it's okay? coverage translates to "amount" in FZ_BLEND? | 09:42.46 |
| tor7 | so to blend two color values 50/50 you really should convert them to a linear space (gamma 1.0), do the math, and then convert back to gamma 2.2 | 09:43.09 |
| | which is what the patch does | 09:43.20 |
| amonakov | ok | 09:43.43 |
| tor7 | input color values get scaled to linear, the coverage blend is applied, and then the result is converted back to srgb before writing | 09:43.44 |
| amonakov | ideally you'd want to do all internal work in linear space, right? without conversion on each blend op | 09:45.05 |
| kens | Hmm, inteeresting. While looking at bmpcmp differences, a file showed a diff that isn't anything to do with pdfwrite. | 09:45.10 |
| tor7 | amonakov: yes, in an ideal world all AA and blending would be done in a linear colorspace | 09:45.37 |
| amonakov | tor7: also, I think you'd need a +127 in ((src - dst) * amount + (dst << 8)) >> 8, otherwise it systematically truncates to zero | 09:45.54 |
| tor7 | but then you need to store a lot more than 8 bits per channel in the buffers | 09:46.04 |
| | amonakov: there's a bit more to the FZ_BLEND story and how it interacts with FZ_EXPAND and FZ_COMBINE | 09:48.13 |
| | but I'm fuzzy on the details | 09:48.39 |
| | the fz_mul255 function does a fixed point (0..255) multiplication with correct rounding | 09:49.26 |
| | but the combination of FZ_BLEND and the other macros are designed to together give the same results with fewer operations | 09:49.47 |
| Robin_Watts | I *think* a +127 wouldn't hurt. | 09:51.01 |
| | or even a +128. | 09:51.08 |
| amonakov | I implemented LCD subpixel antialiasing for zathura mupdf plugin. Looks nice | 09:53.15 |
| kens | really dislikes sub-pixel anti-aliasing | 09:53.43 |
| Robin_Watts | kens: LCD subpixel antialiasing and general sub-pixel anti-aliasing are different beasts though... | 09:54.28 |
| kens | I was assuming LCD sub-pixel here | 09:54.40 |
| | ie ClearType and such | 09:55.08 |
| amonakov | badly implemented lcd subpixel (visibile color fringing) is not good indeed | 09:55.21 |
| kens | I findits visible to me even when not to others | 09:55.34 |
| | SO I dislike it at all settings and implementations. THis is of course, subjective | 09:55.56 |
| chrisl | It might be better on a hires screen like tor7's new laptop..... | 09:56.47 |
| kens | I doubt it. My particular sight condition seems to lead me to see these things. I also pick up flicker where other people don't | 09:57.27 |
| | Weird, I'm seeing missing colours at 72 dpi, but not at 300, from ostensibly the same PDF file (this is pdfwrite). | 09:58.12 |
| | Could be some weird pattern thing I guess | 09:58.30 |
| Robin_Watts | chrisl: tor7's screen is one of the wierd asymettrical ones, so simple LCD subpixel operation won't work. | 09:58.31 |
| chrisl | Robin_Watts: ah, didn't realise that. I was thinking getting subpixel elements smaller would help it - FWIW, I don't like ClearType (or the Linux/X equivalents) either. | 09:59.33 |
| tor7 | chrisl: my new laptop doesn't remotely need lcd coloring fringing to boost the resolution to something passable ;) | 10:00.38 |
| chrisl | tor7: :-) If only they made one with a track point instead of (or as well as) a touch pad, I'd have one.... | 10:01.41 |
| tor7 | kens: DLP projectors must be terrible for you... | 10:02.08 |
| kens | New cinemas are a problem | 10:02.25 |
| tor7 | chrisl: external mouse. the only way you can make linux acceptable on a laptop. | 10:02.28 |
| kens | I tend to get a headache | 10:02.32 |
| chrisl | tor7: I get on fine with a three button track point | 10:03.15 |
| tor7 | kens: not worth it, not for 99% of the usual dross that comes out of hollywood | 10:03.20 |
| kens | Yes, I hardly ever go to the cinema these days.Last time was for the Hobbit and that was a waste of time | 10:03.45 |
| tor7 | chrisl: my only wish would be for three physical buttons on the touchpad. these "clickpad" things are a terrible edie. | 10:03.48 |
| | idea* | 10:03.54 |
| | kens: I made an exception to go see Gravity. that was actually a pleasant surprise! | 10:04.16 |
| kens | didn't see that one | 10:04.33 |
| chrisl | tor7: With touch pads, I always find I accidentally select things when I just want to move the mouse cursor. And the "pad" at the base of my thumb moves the mouse around while I'm typing, which I find *really* annoying. | 10:05.33 |
| Robin_Watts | tor7: Gravity isn't out here yet. | 10:05.33 |
| | saw Enders Game last night. | 10:05.39 |
| tor7 | chrisl: there are some options you can set with the synaptic touchpad driver on linux. like turning it for while typing so you don't accidentally move the mouse around while typing! I really don't understand why that isn't the default though. | 10:06.58 |
| | turning it *off* | 10:07.07 |
| | tap to click is a mixed blessing, but the "click" to click always requires too much force, that the cursor moves off target when you click :( | 10:07.50 |
| chrisl | tor7: I didn't that reliable when I tried it, I guess it may be better now. TBH, I don't want to put in the effort to get comfortable with the touchpad, I've been happy with the track point since the first time I ever tried one | 10:08.43 |
| | s/I didn't that/I didn't find that | 10:09.00 |
| tor7 | Robin_Watts: I'm conflicted about that one. On the one hand, woo! sci fi! On the other, I really can't stand the idea of supporting anything to do with Mr. Card. | 10:09.27 |
| Robin_Watts | I had no idea he was contentious. | 10:09.52 |
| tor7 | chrisl: I've used touchpads since my first laptop, so I think I'm probably just too used to them. | 10:10.01 |
| Robin_Watts | I've never read any of his stuff, but he was responsible for the Sword Fighting Insults in Monkey Island, so that makes him awesome in my book :) | 10:10.47 |
| tor7 | Robin_Watts: he's a rabidly homophobic activist idiot | 10:10.52 |
| Robin_Watts | ah. | 10:11.22 |
| tor7 | he's also a mormon, which might explain it, but doesn't excuse him for being incapable of logic thought | 10:12.15 |
| Robin_Watts | is not going to be drawn into discussing religion vs logic on a public forum. | 10:13.57 |
| tor7 | hm. yes. I should probably stop now before I start ranting... | 10:14.35 |
| | Robin_Watts: so, um, CMYK in PWG? | 10:14.52 |
| Robin_Watts | tor7: If you want to add support, go for it. | 10:15.07 |
| | Otherwise just remove the mudraw changes that make it a possibility. | 10:15.20 |
| tor7 | I am completely unfamiliar with the format, but it *sounds* like it ought to be a reasonable idea. OTOH, given how bad our color conversion functions are, I wouldn't want to encourage its use... | 10:16.07 |
| Robin_Watts | tor7: I don't think it's hard. PWG is basically CUPS output format. | 10:16.36 |
| tor7 | Robin_Watts: which software do you use to view PWG files? | 10:24.49 |
| Robin_Watts | tor7: gawd, now you're asking. | 10:31.07 |
| | rasterview | 10:31.35 |
| tor7 | Robin_Watts: yeah, I managed to track that down and build it. looks like my CMYK changes are fine. | 10:38.27 |
| | Robin_Watts: so, new set of cleaned up patches on tor/master | 10:38.37 |
| Robin_Watts | tor7: excellent. | 10:38.41 |
| | tor7: look good to me. go for it. | 10:39.35 |
| tor7 | Robin_Watts: fab. thanks. | 10:41.24 |
| Robin_Watts | How is a pattern-clist device ending up in gdev_prn_dev_spec_op ? | 11:18.05 |
| | ah, because the clist nastily assumes that all clists are prn devices. | 11:19.04 |
| | tor7: segv central from the clear_pixmap change. | 13:03.14 |
| tor7 | Robin_Watts: really? that's ... unexpected. | 13:14.48 |
| | oh, wait, no null check for pix->colorspace before dereferencing? | 13:15.14 |
| | Robin_Watts: fix on tor/master | 13:19.18 |
| sebras | tor7: yes, I'm at work now. icq died on me. | 13:26.38 |
| tor7 | sebras: feeling jetlagged? | 13:27.08 |
| sebras | tor7: indeed. woke at 3am local time (9am .cn-time) | 13:27.29 |
| | tor7: and got tired at 8pm last night (3am .cn-time) | 13:27.44 |
| tor7 | about expected :) | 13:28.00 |
| sebras | tor7: so I can imagine what your company meetings are like when all europeans go to the .us... | 13:28.20 |
| | tor7: luckily I had no problems going east... | 13:28.46 |
| Robin_Watts | going west 8 hours is comparatively easy. | 13:30.39 |
| | in fact, any single change of direction isn't too bad. | 13:31.00 |
| sebras | Robin_Watts: so... this means that continuing west after visiting .us to back to .uk is recommended? ;) | 13:32.16 |
| Robin_Watts | sebras: Ah, but then we'd all get DVTs and die... | 13:33.01 |
| sebras | Robin_Watts: DVT? | 13:33.11 |
| kens | deep vein thrombosis | 13:33.20 |
| Robin_Watts | Deep Vein Thrombosis - blood clots etc. | 13:33.28 |
| kens | (blood clot) | 13:33.29 |
| sebras | from sitting down too long? | 13:33.40 |
| kens | And in a bent leg position, yes | 13:33.53 |
| Robin_Watts | Lack of movement causes blood pooling in the lower limbs etc. | 13:34.50 |
| | I take aspirin, drink a lot, and (partly due to a bladder the size of a shriveled walnut) move around often. | 13:35.29 |
| sebras | Robin_Watts: I watched three movies yesterday... | 13:36.12 |
| Robin_Watts | sebras: Movies are what I resort to after the laptop battery starts to die :) | 13:36.43 |
| tor7 | Robin_Watts: shriveled walnut bladders ... the dangers of working from home! | 13:37.25 |
| sebras | tor7: well, the cleanliness of swedish schools prevents this... | 13:37.58 |
| tor7 | sebras: Robin_Watts: could one of you please look at tor/master and say "LGTM"? I'd really want to fix that segfault that slipped through. | 13:47.23 |
| Robin_Watts | looking. | 13:48.48 |
| | tor7: lgtm | 13:49.00 |
| sebras | tor7: lgtm | 13:49.41 |
| | tor7: but are there other instances of the same problem..? | 13:49.50 |
| | tor7: I can see that colorspace->n is used elsewhere, but I didn't check the code paths. | 13:51.10 |
| tor7 | sebras: it's a fix to a patch two earlier | 13:51.33 |
| sebras | tor7: I'm not sure I get that. | 13:52.19 |
| tor7 | commit f975089 Special case clear_pixmap_with_value for CMYK colorspaces | 13:52.48 |
| | dereferences colorspace without checking first | 13:53.03 |
| | a rare few other instances of that have bitten us before, and been fixed | 13:53.23 |
| sebras | tor7: yes, but I'm thinking about _other_ places in the repo. | 13:53.24 |
| tor7 | it's part of the deal, pixmaps without a colorspace are treated as alpha only | 13:53.46 |
| | s/deal/API/ | 13:53.54 |
| sebras | tor7: right, maybe the other places only handle pixmaps with colorspaces and check for this elsewhere. | 13:54.21 |
| tor7 | sebras: yup. | 13:54.35 |
| ray_laptop | Robin_Watts: sorry about the clist spec_op mess. I should have thought of the fact that clist is used for patterns. I wonder how this ever worked in regression. | 14:50.11 |
| Robin_Watts | ray_laptop: No worries. I think the solution I implemented should be the cleanest way. effectively every clist now knows if it's a prn or not. | 14:54.53 |
| ray_laptop | Robin_Watts: OK. I _do_ wonder how this worked | 14:55.41 |
| mvrhel_laptop | bbiaw | 15:11.50 |
| ray_laptop | Robin_Watts: stepping through gdev_mem_set_planar, why does it only set the mem_planar_fill_rectangle_hl_color and mem_planar_put_image if num_planes >= 4 ??? | 15:29.02 |
| | Robin_Watts: can you remember from Apr 2012 ;-) | 15:32.30 |
| | Robin_Watts: it doesn't seem to make sense, and doesn't match the comment above it | 15:35.22 |
| | I guess when it calls the default fill_rectangle_hl_color it's counting on it calling mem_planar_fill_rectangle | 15:43.53 |
| | darn. Have to duck out for a bit. bbiaw | 15:44.07 |
| Robin_Watts | ray_laptop: Sorry, back. | 15:45.36 |
| kens | hehe engineer ping-pong | 15:45.53 |
| ray_laptop | Robin_Watts: I'll check the logs later, and it seems to work, so don't worry about it. It just seemed curious | 15:46.29 |
| | bbiaw | 15:46.41 |
| Robin_Watts | ray_laptop: How is the alignment stuff going? Presumably you are back on Len stuff now ? | 15:46.52 |
| | I think the comment above it makes sense. I also think that mvrhel wrote it. | 15:52.34 |
| | This is the commit that ended up being listed as me, but was mostly mvrhel I think. | 15:53.22 |
| henrys | mvrhel_laptop: are you good with marti's proposal if so I'll talk $'s with him. | 16:17.39 |
| Robin_Watts | henrys: Did you see the last reply from 801? That explains their use of tiff. | 16:18.56 |
| | I think, with the exception of the unaligned stuff that ray is working on now, we're done for now. | 16:19.20 |
| | so... I might get back to what I was doing before. If I can remember what I was doing before... | 16:20.01 |
| henrys | Robin_Watts: I browsed it I have 5 other things in front of it. | 16:20.09 |
| | but that is great amazing quick work Robin_Watts | 16:20.38 |
| Robin_Watts | henrys: Sure. basically they were doing tiff to experiment with 1 and 4 color support. | 16:20.49 |
| | henrys: turned out much easier than it might have been. | 16:21.00 |
| henrys | Robin_Watts: I just worry about it being right - I wonder if marcosw could do some sort of quick visual diff as he does against a known to work device like tiffsep (using their profiles) | 16:22.29 |
| Robin_Watts | henrys: What bit of it do you think might be wrong? The profile handling? | 16:23.05 |
| | or the halftoning? | 16:23.17 |
| | mvrhel_laptop did some tests on the profile handling, but not a full cluster run. | 16:24.49 |
| henrys | Robin_Watts: is tiffsep planar native or is there a conversion at the back end? | 16:24.56 |
| Robin_Watts | tiffsep is planar native, I believe. | 16:25.20 |
| henrys | Robin_Watts: most generally I'm worried about planar in general - it is new for us really. | 16:25.49 |
| Robin_Watts | yeah, tiffsep calls gdev_prn_open_planar | 16:26.31 |
| | as does psdcmyk. | 16:27.04 |
| | And we test psdcmyk all the time. | 16:27.14 |
| | I stole the device setup largely from psdcmyk. | 16:27.28 |
| henrys | Robin_Watts: well then we might be safe. | 16:29.46 |
| | Robin_Watts: it would be good to check that our performance at least matches the old code once alignment is done. sending them something dramatically slower would be bad. | 16:31.46 |
| Robin_Watts | OK. Let me try some performance tests. | 16:32.11 |
| kens | needs to go carve a pumpkin, bye all | 16:56.18 |
| ray_laptop | bye, kens | 16:56.40 |
| henrys | ray_laptop:weren't you doing some sort of printing from the ipad? | 16:58.55 |
| | folks are asking us about "AirPrint" certification - apparently you have to blessed by Apple in some way - it's all clear as ice - like usual. | 17:00.08 |
| | Google print is open and documented. | 17:00.34 |
| Robin_Watts | Airprint requires blessing by google. | 17:00.43 |
| | Airprint requires blessing by apple. sorry. | 17:00.55 |
| | The recent performance panics from 532 were over them getting their Airprint certification. | 17:01.11 |
| henrys | Robin_Watts: oh right ⦠how silly of me to forget that. | 17:01.46 |
| | Robin_Watts: thank you | 17:02.03 |
| Robin_Watts | So the answer to give is that "yes, we have customers who have used gs as the basis of their printing solution who have got AirPrint certification" | 17:02.15 |
| henrys | Robin_Watts: it would be nice if we could get the certification - apparently CSR/Zoran does have it, I don't know how they can do that without a real device but they have. | 17:03.18 |
| Robin_Watts | but given that people are building gs into their own products, we can't get gs certified and expect that to transfer to customers products. | 17:03.20 |
| henrys | see above | 17:03.32 |
| Robin_Watts | I bet their is some complex language going on in the small print on their claims. | 17:04.02 |
| | s/their/there/. Bad Robin, bad. | 17:04.11 |
| ray_laptop | henrys: I've been swamped with customer issues, but I want to put Bonjour on my Pi and set it up to mimic an Airprint printer, then we can run gs or mupdf. | 17:04.33 |
| henrys | Robin_Watts: no I imagine CSR is in so many printers that apple really couldn't say no to them, but I'm speculating | 17:04.45 |
| ray_laptop | That *might* be enough for us to get certified | 17:04.56 |
| Robin_Watts | OK, I've nobbled their device to not actually output anything. And I've nobble my device to not actually output anything. | 17:05.35 |
| | Running 10 tiger.eps at 600dpi on their device... 3.8 seconds. | 17:05.54 |
| | Running 10 tiger.eps at 600dpi on my device... 3.1 seconds. | 17:06.05 |
| | That's with NumRenderingThreads=4 | 17:06.15 |
| ray_laptop | henrys: or we may be able to work with cust 532 to have them tell Apple that we are how they process when running from Airptint | 17:06.17 |
| Robin_Watts | ray_laptop: Are you still bashing your head on the alignment stuff? | 17:06.52 |
| | Would you like to hand that off to me, so you can get back to Len stuff? | 17:07.09 |
| henrys | ray_laptop: it would be nice if you could bring that up with 532 when you get a chance? | 17:07.14 |
| ray_laptop | Robin_Watts: that's pretty slow. what are you running on ? | 17:07.23 |
| Robin_Watts | My Core 2 Quad box. | 17:07.43 |
| ray_laptop | Robin_Watts: on my laptop, even a debug build to bitcmyk -dGrayValues=256 -o /dev/null is 1.8 seconds | 17:08.09 |
| | a release build is 1.2 sec | 17:08.29 |
| Robin_Watts | 10 pages? | 17:08.33 |
| ray_laptop | oops. I missed that. | 17:08.57 |
| henrys | Robin_Watts: altona files or something that is going to use all the color planes? | 17:09.01 |
| ray_laptop | Robin_Watts: so, to make it more dramatic, since the improvements are in rendering, set #copies to 10 | 17:09.38 |
| Robin_Watts | ray_laptop: I just did gs -sDEVICE=.... gs/examples/tiger.eps gs/examples/tiger.eps gs/examples/tiger.eps gs/examples/tiger.eps gs/examples/tiger.eps gs/examples/tiger.eps gs/examples/tiger.eps gs/examples/tiger.eps gs/examples/tiger.eps | 17:10.22 |
| | So only 1 program start. | 17:10.34 |
| Robin_Watts | is lo-tech :) | 17:10.48 |
| | Ha, their device crashes on Altona_Measure_1v1.pdf | 17:14.11 |
| ray_laptop | Robin_Watts: I had only tried it once. Something else may have been slowing me down. Now running release build with 10 files as you did is giving me 1.38 sec (fastest of 5 tries) | 17:15.10 |
| | with NumRenderingThreads=4 I get 1.26 sec | 17:15.52 |
| Robin_Watts | ray_laptop: Want me to upload binaries for you to try? Theirs and mine? | 17:15.57 |
| ray_laptop | Of course, their device has to do all that extra processing (5 planes, BNM and 600->300 and 4 bit packing) | 17:16.40 |
| | Robin_Watts: no, that's OK. | 17:16.53 |
| henrys | Robin_Watts: maybe I'll ping michael sweet about that. | 17:17.59 |
| | or ray_laptop ^^^ he's probably in the know | 17:18.17 |
| Robin_Watts | about AirPrint? Yeah, that sounds like a good idea. | 17:18.28 |
| henrys | right AirPrint sorry | 17:18.43 |
| ray_laptop | henrys: All I know is what I've learned from Googling about what it takes to share a printer on a linux box over Airprint. I haven't looked at certification | 17:23.28 |
| | And I *certainly* don't know anybody at Apple | 17:23.51 |
| | lets just make sure that it isn't Miles that asks Apple about getting certification ;-) | 17:24.27 |
| henrys | ray_laptop: you probably do and they just don't admit it ;-) | 17:24.33 |
| | ray_laptop: indeed | 17:24.46 |
| Robin_Watts | ray_laptop: Are you still bashing your head on the alignment stuff? | 17:57.24 |
| | Ah, if I set the bandheight to a multiple of 16 I can stop the overflow in their code. | 18:09.41 |
| | So 600dpi, 4 threads bandheight=128, Altona_Measure_1v1.pdf 12.7s with theirs, 1.8 with ours. | 18:11.19 |
| | I don't believe that speed difference is due to the device though. I think there may be a 9.06 vs 9.10 thing at play. | 18:11.58 |
| ray_laptop | Robin_Watts: I've gotten rid of segfaults, but I now have Differences in 3136 of 50285 non-pdfwrite/ps2write test(s) | 19:05.59 |
| Robin_Watts | ray_laptop: Do you have Len work to be getting on with? | 19:06.21 |
| ray_laptop | that's without forcing the alignment and pad to non-standard values | 19:06.23 |
| Robin_Watts | would you like me to have a look ? | 19:06.27 |
| ray_laptop | Robin_Watts: I am working on Len's stuff while the regression runs. | 19:06.48 |
| Robin_Watts | ok. | 19:06.56 |
| | Well, just let me know if I can help out. | 19:07.05 |
| ray_laptop | If you want to look at the bmpcmp and see what might be funky, fine with me. I have a show at the school this PM so I'll be out in a few minutes (and probably won't be able to work much) until about 4pm (~4 hours from now) | 19:08.19 |
| | Robin_Watts: I'll push the mess up to my repo | 19:08.34 |
| Robin_Watts | ray_laptop: Thanks. | 19:08.40 |
| ray_laptop | in gdevmem.c there is a #ifdef TEST_ALIGN_AND_PAD that sets a non-standard mod and pad. BTW, the diffs were with the standard align_bitmap_mod and pad=0 | 19:11.07 |
| | Robin_Watts: heading out now for lunch, then to to school, but text me if you want me online. | 19:12.35 |
| Robin_Watts | ok, thanks. I may be being called away soon. | 19:13.18 |
| ray_laptop | Robin_Watts: I'm not sure how it will end up on my git repo. I did a push -f personal from a 'padding changes' branch | 19:13.38 |
| | I get to watch 90 kids each stand up and tell about their "Historical Halloween" person (my son is Isaac Newton this year) | 19:14.37 |
| Robin_Watts | push -f personal padding_changes | 19:14.40 |
| ray_laptop | Robin_Watts: even when padding_changes is my current branch ? | 19:15.02 |
| Robin_Watts | That will make a padding_changes branch on the remote. | 19:15.04 |
| | actually... | 19:15.23 |
| | I can see a commit, 38 mins ago with the stuff in on master. | 19:15.40 |
| | so I'll work with that. | 19:15.55 |
| ray_laptop | Oh, maybe it pushed to the master on personal. That'll do. But the clocks must be screwy because it was only 5 min ago | 19:16.42 |
| Robin_Watts | d43f71f1e964feaf99bb445a8d8b281c620dc9d9 ? | 19:17.05 |
| ray_laptop | Robin_Watts: you can look at the diffs after you pull it to a branch on your side | 19:17.08 |
| Robin_Watts | http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=d43f71f1e964feaf99bb445a8d8b281c620dc9d9 | 19:17.17 |
| | I can see the diffs online :) | 19:17.25 |
| ray_laptop | Robin_Watts: I am on d43f71f | 19:17.32 |
| Robin_Watts | perfect. That's what's in the repo. | 19:17.46 |
| ray_laptop | Robin_Watts: OK. bbiaw (4 hrs) | 19:17.51 |
| Robin_Watts | so, basically, psdcmyk is broken. but everything else is OK. | 19:40.45 |
| | possibly cos that's the only planar device we test. | 19:42.48 |
| mvrhel_laptop | sorry I was out most of the morning | 19:47.02 |
| | henrys: I did not get a chance to read his proposal. I will read it this afternoon | 19:48.47 |
| Robin_Watts | It's basically what he had before with some times attached. | 19:50.24 |
| | In fact, it's just clist planar that's broken. | 20:22.19 |
| | And it's to do with the calculation of raster in clist_rasterize_lines | 20:22.38 |
| | which doesn't seem to take account of the fact it's planar. | 20:22.48 |
| | I suspect that clist_plane_raster may need to be changed. | 20:23.52 |
| | yeah, if I fiddle clist_plane_raster, I can make it work. | 20:29.35 |
| | BUT the fiddle I've got will not play nice with non-standard alignments/paddings. | 20:30.12 |
| mvrhel_laptop | Robin_Watts: so I see the customer wanted 8 bit pgm's also. so it was not just me ;) | 21:29.18 |
| nomi1988 | Can the MuPDF library be used in Android app freely? | 22:17.08 |
| Robin_Watts | mvrhel_laptop: No, it was a sensible request. | 23:57.44 |
| | nomi1988: If you abide by the terms of the GNU AGPL. | 23:58.00 |
| | Or you can get a commercial license from Artifex that will allow you to do what you want with it. | 23:58.16 |
| ray_laptop | Robin_Watts: you beat me to it, answering nomi | 23:58.20 |
| Robin_Watts | ray_laptop: Did my babblings in the email make any sense? | 23:58.39 |
| ray_laptop | Robin_Watts: I see that you've narrowed down the issue with psdcmyk | 23:58.49 |
| | so, it doesn't crash, but gets the wrong thing (looks like almost always black) | 23:59.57 |
| | Forward 1 day (to 2013/11/01)>>> | |
IRC Logs