| | <<<Back 1 day (to 2012/03/15) | 2012/03/16 |
| Robin_Watts | Presumably chrisl did that :) | 15:48.52 |
| chrisl | I did..... | 15:48.58 |
| Robin_Watts | There is a script for running ghostbot. | 15:49.07 |
| ray_laptop | thanks to whoever | 15:49.09 |
| chrisl | Just couldn't type fast enough to tell ray_laptop! | 15:49.16 |
| ray_laptop | Robin_Watts: I knew there was a script -- just couldn't remember the path for it | 15:49.38 |
| | chrisl: better to spend the keystrokes doing it rather than talking about it ;-) | 15:50.03 |
| chrisl | ray_laptop: you have to run it as the ghostbot user, otherwise we get all the haywire problems with it like we did last year....... | 15:50.28 |
| ray_laptop | chrisl: so I do: sudo su ghostbot | 15:50.54 |
| chrisl | ray_laptop: Yes, then /home/ghostbot/RUN_GHOSTBOT | 15:51.29 |
| Robin_Watts | chrisl, ray_laptop, henrys: In gxclimag.c, our code has #ifdef DEBUG surrounding the if (gs_debug_c('v')) calls. Their code does not. | 15:52.55 |
| | I wonder if this is a common problem. | 15:53.25 |
| ray_laptop_ | I better move to where there's a better connection | 15:53.27 |
| henrys | yes but dprintf shouldn't even be defined, I thought a different i/o function was used for -Z: stuff. | 15:54.30 |
| chrisl | Robin_Watts: I thought the compile time conditional stuff was done inside gs_debug_c() | 15:55.34 |
| Robin_Watts | Nope. | 15:56.00 |
| | gs_debug_c is in regardless. | 15:56.17 |
| chrisl | Still, it means Ray it correct about them not using a debug build..... how hard is this?!?! | 15:57.35 |
| henrys | Robin_Watts:and dprintf is defined? | 15:58.16 |
| Robin_Watts | henrys: I think so. | 15:58.40 |
| | dlprintf at least. | 15:58.59 |
| | I'm just running through their code looking for places where gs_debug_c is called without #ifdef DEBUG guards. Look to be a fair few. | 15:59.39 |
| henrys | if there are a lot of those it can be a performance problem, we've seen checking the if if in a tight loop have real effects. | 16:00.08 |
| | chrisl:no I think the engineering resources are terribly lacking over there which is why I've been asking you and ray to push back, it won't change until we do that. There's no reason for it to change if we solve everything for them. | 16:05.39 |
| | ray_laptop must be in his sheided bunker. | 16:13.13 |
| mvrhel | bbiaw | 16:14.32 |
| ray_laptop__ | should be a better connection now | 16:15.08 |
| tor8 | Robin_Watts: fts42 looks like it could be something with nested visualbrushes | 16:15.10 |
| | the tile within the tile area is outside the visible region. but I don't see how :( | 16:15.35 |
| Robin_Watts | tor8: ew. | 16:17.29 |
| | chrisl: Does 532 use gxttfb.c ? | 16:17.48 |
| chrisl | Robin_Watts: I would think they must, yes | 16:19.09 |
| ray_laptop | cust 532 on 6thgen is using UFST, but presumably that is only for the fonts in the FCO | 16:20.10 |
| | they don't use FT on any products (yet) | 16:20.35 |
| | Robin_Watts: what are you getting at ? (about gxttfb.c) | 16:21.05 |
| Robin_Watts | ray_laptop: I'm looking for files that contain calls to gs_debug_c even in release mode. | 16:21.34 |
| ray_laptop | ah, I see. | 16:21.48 |
| | There are a few that do that intentionally -- e.g. for -Z: | 16:22.05 |
| Robin_Watts | ray_laptop: Sanity check me here... | 16:22.27 |
| | ialloc_validate_ref should do nothing unless -Z? is defined ? | 16:22.48 |
| | Ignore me. I found the #ifdef DEBUG. | 16:24.14 |
| ray_laptop | Robin_Watts: right, line 145. The functions are no-op following line 580 | 16:25.39 |
| | Robin_Watts: what does that have to do with gxttfb ? | 16:26.59 |
| Robin_Watts | Again, I'm looking for places that call gs_debug_c from release mode. | 16:27.20 |
| | I couldn't see the #ifdef DEBUG which that call to gs_debug_c was enclosed in. | 16:27.41 |
| ray_laptop | Robin_Watts: from the profiles I think we were seeing very few calls to that (per page) | 16:28.04 |
| Robin_Watts | ray_laptop: The presence of a call to gs_debug_c can slow down code more than the time taken to perform that call. | 16:29.27 |
| ray_laptop | Robin_Watts: how ? | 16:29.46 |
| Robin_Watts | For a start there is the time taken to stack/unstack registers around the call. | 16:29.53 |
| ray_laptop | goes to look at the profiles... | 16:30.28 |
| Robin_Watts | Then there can be the issue that if gs_debug_c is the only out of scope call made by a function, it can radically affect what optimisations can be done to that function. | 16:30.31 |
| | Quite a lot of the time we see: if (gs_debug_c('s')) { make various calls; } | 16:31.09 |
| henrys | it seems like not something to argue about tell them to bracket the calls and move on. | 16:31.10 |
| Robin_Watts | henrys: Right, that was my plan. | 16:31.34 |
| henrys | is it easy to get a list of all of them? | 16:32.03 |
| Robin_Watts | henrys: I am constructing such a list now. | 16:32.18 |
| ray_laptop | Robin_Watts: in the recent 10 page profile, I see 43599/43689 from clist_fill_mask | 16:32.43 |
| Robin_Watts | That's checking for '`' | 16:34.12 |
| | I believe '`' is use to disable complex clipping ? | 16:34.24 |
| ray_laptop | Robin_Watts: that call is to enable one of the test modes, but they never use it, and even for our release we can make it only in a DEBUG build. | 16:34.59 |
| Robin_Watts | Indeed. | 16:35.06 |
| | I will send a mail. | 16:35.21 |
| ray_laptop | but given the number of calls to the clist_fill_mask, I can't imagine that gs_debug_c will be a contributor. The time doing the gs_debug_c is .077 out of 7.88 in clist_fill_mask | 16:37.53 |
| Robin_Watts | ray_laptop: No, in that case it's probably not a huge time drain, because clist_fill_mask is not otherwise a leaf function. | 16:38.38 |
| henrys | kens:yes pcl transparency strikes again. | 16:39.44 |
| | actually it doesn't detract from the content - of course it is wrong. | 16:40.09 |
| ray_laptop | 3 days of rain -- snow in local mountains expected (snow level down to 5,000 ft which affects the major passes) | 16:46.44 |
| Robin_Watts | Highest road in Cali is 10000 ft or something, right? | 16:47.20 |
| kens | henrys, you mean this is raster ops ? | 16:47.22 |
| ray_laptop | mvrhel: thanks for sending the precipitation to us :-) | 16:47.37 |
| kens | henrys In which case there is nothing we cna do to fix it ? | 16:47.56 |
| ray_laptop | Robin_Watts: Mt. Baldy and Mt. Ontario (so cal) are over 10,000 ft. Big Bear (local ski resorts) is at 8,000 ft | 16:48.48 |
| henrys | kens:right | 16:49.01 |
| Robin_Watts | Tioga Pass is the highest pass, I thought. Professor google says 9945 ft. | 16:49.20 |
| kens | henrys Oh :-( Will you write something in the bug report ? | 16:49.40 |
| henrys | starts to wonder if text + raster is the way to go with pcl->pdf afterall. | 16:49.49 |
| | kens:will do. | 16:49.54 |
| Robin_Watts | (sorry, highest road != highest pass, obviously) | 16:49.55 |
| kens | henrys thanks, did you send tehm to Sctoo too ? | 16:51.14 |
| | Scott | 16:51.20 |
| henrys | kens:no I'll do that also. | 16:54.43 |
| ray_laptop | Robin_Watts: Tioga pass is in No. CA, but the passes into the LA basin are both > 6,000 feet. Also even if it just rains, the next few nights are getting down to the teens (F) so freezing is problem on overpasses | 16:58.46 |
| kens | henrys just got another PCL->PDF from custoemr #1 re their EPA printouts | 16:59.00 |
| | I'll forward it on to support | 16:59.11 |
| henrys | lucky us | 16:59.17 |
| kens | ANd CC on my reply later | 16:59.19 |
| | :-( | 16:59.27 |
| ray_laptop | kens: remind them to send to support (or at least CC support) please | 16:59.38 |
| kens | I will Ray, I always do :-( | 17:00.17 |
| Robin_Watts | tor8:FWIW, it kills gxps too. | 17:01.20 |
| | (SEGV) | 17:01.25 |
| henrys | kens:all done | 17:12.19 |
| kens | THanks henrys | 17:12.26 |
| henrys | off for a bike ride bbiab | 17:24.00 |
| kens | Goodnight everyone.... | 18:06.59 |
| Robin_Watts | night kens. have a good weekend. | 18:07.09 |
| | tor8: got time for a quick sanity check please? | 18:20.38 |
| | There is a note in pdf_load_jpx that says "We can't handle decode arrays for indexed images currently". | 18:23.54 |
| | That implies to me that we can handle indexed images without decode arrays. | 18:24.08 |
| | But I can't see where... | 18:24.12 |
| tor8 | I ... don't remember | 18:29.34 |
| Robin_Watts | I'd expect an indexed image to decode from the internal decoder into a 1 component image, which we would then look up to get an n component image. | 18:30.30 |
| tor8 | the decode argument for indexed images is given special treatment in the spec, right? | 18:31.55 |
| Robin_Watts | And indeed, this image, which is supposed to be shades of red, is in a 2 separation space (M and Y), so the index lists lots of 'pairs' of bytes, which seems consistent to me. | 18:32.22 |
| | There is no decode argument in this case. | 18:32.31 |
| | BUT... the jpx decode from openjpeg is giving me back 2 components in the output. | 18:32.59 |
| | Presumably 1 component + alpha ? | 18:33.15 |
| tor8 | you must have a colorspace in to fz_load_jpx then? | 18:34.15 |
| | and yes, the pixmap out of fz_load_jpx always has an alpha channel | 18:34.59 |
| Robin_Watts | Yes. | 18:35.08 |
| | And it's not the pixmap out I'm worried about. | 18:35.21 |
| | It's the samples out from the decoder itself. | 18:35.28 |
| tor8 | jpx->numcomps == 2 ? | 18:35.50 |
| Robin_Watts | Yes. | 18:36.25 |
| | jpx->color_space = CLRSPC_GRAY | 18:36.49 |
| tor8 | SMaskInData set? | 18:40.50 |
| Robin_Watts | Where is that ? | 18:41.46 |
| tor8 | it should be set in the image dictionary if the image has an inline alpha channel | 18:42.04 |
| | which should be the case if you have numcomps==2 and colorspace==gray | 18:42.22 |
| Robin_Watts | No. | 18:42.32 |
| | There is no SMaskInData in the file | 18:42.38 |
| tor8 | could fz_premultiply_pixmap be messing up the indexed colors though? | 18:42.58 |
| Robin_Watts | I've got the code stopped before fz_premultiply_pixmap is called. | 18:43.14 |
| tor8 | we have a test for CMYK to convert that to RGB so we can premultiply | 18:43.19 |
| Robin_Watts | because, yes, I think that's wrong. | 18:43.22 |
| tor8 | so we should expand any indexed colorspaces before premultiplying as well | 18:43.37 |
| Robin_Watts | At the moment I'm just trying to understand what I'm getting from the jpx decoder. | 18:43.42 |
| | component 0 contains mostly 0's and some numbers up to around 0x2c ish, which is about right, because the index is 51 long. | 18:44.24 |
| | component 1 contains mostly 0's and some number also up to around 0x2cish - but fewer bytes set than component 0. | 18:45.08 |
| | I wonder if we should ignore the alpha plane. | 18:45.24 |
| | Actually, I lie. The 2 planes look identical. | 18:49.16 |
| | ok. I can work from here, thanks. | 18:50.15 |
| kens | tor8 Robin_Watts ping | 20:22.34 |
| Robin_Watts | pong | 20:23.43 |
| kens | Robin_Watts : I sent an email from Nicole Diaz (customer #1) to support earlier with a PDF attached could you try it on current MuPDF please ? | 20:24.10 |
| | SHould be totally black, but the 0.9 version shows a green bar and some orange and purple lines | 20:24.32 |
| | Filename is a long string of numebrs | 20:24.58 |
| | THe area where there is white text "government 5-star safety ratings" should be black and is green on MuPDF 0.9 | 20:25.44 |
| Robin_Watts | It's green on head too. | 20:25.59 |
| kens | Oh, OK then I'll simplify annd report a bug | 20:26.08 |
| | I want to see what's in there before I report it | 20:26.18 |
| | But I thought it was worth checking current code first | 20:26.26 |
| | Thanks | 20:26.29 |
| Robin_Watts | np. | 20:26.31 |
| henrys | marcosw:I forgot about the meeting I'll be around in about 1/2 hour if you want to do it today. | 20:30.30 |
| tkamppeter | Next week is beta2 freeze for Ubuntu Precise. Currently I have packaged a nearly patchless GS 9.05. Are there any after-9.05 patches which I should apply, due to important bugs in 9.05? | 20:39.56 |
| henrys | tkamppeter:the only thing jumps out at me are the Default ICC profile changes but you should consult with mvrhel about that. | 20:47.38 |
| mvrhel | I think that break happened post 9.05 | 20:52.08 |
| | tkmappeter, henrys | 20:52.21 |
| henrys | oh okay | 20:52.59 |
| tkamppeter | mvrhel, so 9.05 is OK> | 21:17.45 |
| | ? | 21:17.48 |
| mvrhel | tkamppeter: yes I believe so | 21:18.01 |
| | it does not have the output intent changes in it, but I do not want to fool with porting that | 21:18.23 |
| tkamppeter | mvrhel, OK, thanks. | 21:21.31 |
| Robin_Watts | Gah. The JP2X image has the same palette in that the PDF file has; so somehow we are trying to apply it twice? This hurts my head too much for a friday night. | 21:57.45 |
| | Forward 1 day (to 2012/03/17)>>> | |
IRC Logs