| | <<<Back 1 day (to 2016/03/24) | 20160325 |
| sebras | tor8: Robin_Watts: I got a report from malc_ about not being able to decode the Arch Linux splashscreen bitmaps so I fixed the issues I believe. Please take a look when you have time. | 10:01.09 |
| Robin_Watts | sebras: Will do. | 10:06.34 |
| sebras | Robin_Watts: I also updates the bmp testsuite correspondingly. | 10:08.33 |
| malc_ | sebras: works like a charm for me, tack igjen (though that's not Swedish i suppose) | 10:10.52 |
| sebras | malc_: almost: igen. :) | 10:12.14 |
| | malc_: sure, no problem. | 10:12.19 |
| malc_ | barbarian language | 10:12.30 |
| | i suppose we will see igen from apple in the future, and then .se would have to fix it's dictionaries | 10:13.05 |
| | just you wait | 10:13.07 |
| tor8 | Robin_Watts: so, with all this talk about performance ... how about making alpha optional and extending the plotters to deal with non-alpha destination buffers? | 12:01.33 |
| | and add a 'stride' field to the fz_pixmap struct and using that everywhere | 12:01.48 |
| Robin_Watts | tor8: That'd mean an explosion in unrolled loops. | 12:06.21 |
| tor8 | Robin_Watts: yes. 4x as many as now... | 12:06.35 |
| Robin_Watts | losing alpha would help for cmyk, but hurt for rgb. | 12:06.36 |
| tor8 | it might help grayscale as well | 12:06.50 |
| Robin_Watts | It might. | 12:07.01 |
| tor8 | depending on memory bandwidth pressure | 12:07.03 |
| | if we do go ahead with this, I'm thinking we're going to have to either write code generators or repeat your paint-glyph macro madness for all plotters | 12:07.40 |
| | adding proper non-aa scan conversion with proper pixel filling rules is probably a much higher priority, imo | 12:08.42 |
| Robin_Watts | Yes, I think performance is good enough at the moment. | 12:09.03 |
| | I had a "D'Oh" moment this morning when I realised that I hadn't been testing my code with ARCH_ARM defined on the pi, hence hadn't been testing all my shiny new ARMness. | 12:11.04 |
| | which turned out to be broken new ARMness :( | 12:11.13 |
| | which I am fixing now. | 12:11.17 |
| | OK, with stuff actually working, ARM coding the halftoner has saved 1/3 of the time per page. | 12:21.23 |
| tor8 | ohhh. oops :) | 12:21.45 |
| Robin_Watts | yeah, so all rayjj's figures are still valid, they are just for the C only version. | 12:23.21 |
| | tor8: At the moment I have an ARCH_ARM_CAN_LOAD_UNALIGNED define. | 13:15.55 |
| | I want to change it to just be ARCH_UNALIGNED_OK | 13:16.10 |
| | tor8: any objections ? | 13:16.44 |
| tor8 | is it generic or arm specific? | 13:19.21 |
| | ARCH_USE_UNALIGNED_LOAD but I guess that's still too long? | 13:19.48 |
| Robin_Watts | It is now non arm specific. | 13:20.42 |
| | and it's for both load and store. | 13:20.49 |
| Robin_Watts | foods. | 13:21.37 |
| hartmut | HI, I'm the developer of python-ghostscript, an interface to use the ghostscript api from Python. | 14:07.29 |
| | ATM I'm treid to complete a tet-suit. | 14:07.41 |
| | And I'm failing to redirect stdout using gsapi_set_stdIO(). | 14:08.04 |
| | My output device is bmp16. | 14:08.49 |
| Robin_Watts | hartmut: Have you been talking to Ken and Chris about this? | 14:09.24 |
| hartmut | If I'm passing -OutputFile=-, the image data is written to the stdout instead of passing to the stdout-function I've set with gsapi_set_stdio(). | 14:10.14 |
| | And when leaving -Outputfile away, I get the error: Could not open the file .GPL Ghostscript 9.14: Unrecoverable error, exit code 1 | 14:11.09 |
| Robin_Watts | hartmut: That doesn't entirely surprise me. | 14:11.26 |
| hartmut | Robin_Watts: No. I just started looking for help | 14:11.36 |
| Robin_Watts | This is *not* my area really, but I thought that the purpose of the stdout redirection was so you could redirect the backchannel stuff from postscript. | 14:12.08 |
| | When you use -OutputFile=- that's an instruction to the device, so a different kettle of monkeys. | 14:12.40 |
| hartmut | Hmm, this what I'm afraid of. | 14:13.45 |
| | Unfortunatly gsapi_set_stdIo is not well documented. | 14:14.16 |
| Robin_Watts | hartmut: You really need chrisl or kens, but we're into a long weekend here, so they may not be around until next tuesday. | 14:14.47 |
| hartmut | Robin_Watts: Okay, So I'll step by next week (if I find some time). Or can I ask thin on gs-devel? | 14:16.19 |
| | s/thin/this/ | 14:16.35 |
| Robin_Watts | Sure, asking on gs-devel is a good place. | 14:16.55 |
| hartmut | Robin_Watts: Fine. I'll ask there then. Enjoy your long weekend :-) | 14:19.58 |
| | bye | 14:20.00 |
| Robin_Watts | tor8: OK, various commits on robin/master | 14:20.47 |
| | If we can get the first 6 of those in, then rayjj can rerun the timings. | 14:21.26 |
| tor8 | (uint32_t *)(void *)samples does that void* cast need to be there? | 14:24.44 |
| Robin_Watts | casting from a char * to an int * can give warnings about "cast increases the required alignment" | 14:27.30 |
| tor8 | fz_paint_solid_color_5 uses ARCH_UNALIGNED_OK before the rename | 14:27.37 |
| Robin_Watts | and the (void *) thing shuts that up. | 14:27.43 |
| | oops, will reorder, thanks. | 14:27.50 |
| tor8 | Robin_Watts: oh, what rubbish compilers :) | 14:27.55 |
| | but yes, I guess so... | 14:28.07 |
| | Robin_Watts: I'd prefer _OKAY (okay is a real word, not an acronym) | 14:28.37 |
| Robin_Watts | OKAY is not a real word. | 14:28.55 |
| | OKAY is at best a phoneticisation of OK :) | 14:29.12 |
| | zlib uses ALIGNED_OK | 14:29.42 |
| | so we're in sane company. | 14:29.56 |
| tor8 | "Whether this word is printed as OK, okay, or O.K. is a matter normally resolved in the style manual for the publication involved. Dictionaries and style guides such as the Chicago Manual of Style and The New York Times Manual of Style and Usage provide no consensus." | 14:30.48 |
| Robin_Watts | sebras: All your commits look fine to me, except the last one, which I'm struggling with. | 14:30.52 |
| | You've extended web_palette to be 300 entries. | 14:31.35 |
| | and you copy out of it using a memcpy with sizeof(web_palette) - readcolors*3 | 14:32.25 |
| | but nowhere can I see that readcolors is clamped to between 0 and 100. | 14:32.38 |
| tor8 | Robin_Watts: if okay is not a word, what's OK an abbreviation of? | 14:33.09 |
| | (BTW, all commits LGTM) | 14:33.26 |
| Robin_Watts | tor8: It's not an abbreviation of anything. It's just a noise. | 14:33.51 |
| | Like "uh-huh" | 14:34.13 |
| | or "wow" | 14:34.25 |
| | tor8: Thanks. | 14:34.45 |
| rayjj | Robin_Watts: I saw the email about ARM optimizations. I've pulled from golden and am rebuilding, then will retest CMYK and mono | 14:58.17 |
| HenryStiles | OK is short for "oll korrect" slang from the part of the US where my family comes from... new york area | 14:58.59 |
| Robin_Watts | rayjj: fab. | 14:59.32 |
| | HenryStiles: So, I modified those margins. | 14:59.43 |
| | left border might have moved a smidge, but not much. | 15:00.15 |
| mvrhel_laptop | rayjj: let me know if you do an update of the wiki please | 15:00.38 |
| Robin_Watts | I suspect it's just paper handling tolerances. | 15:00.42 |
| | THe image moved the expected amount though. | 15:00.59 |
| | and the right hand border moved in unexpectedly. | 15:01.15 |
| HenryStiles | Robin_Watts: with tiger not a problem , but an origin sensitive job is probably going to look translated. | 15:01.41 |
| Robin_Watts | HenryStiles: Indeed. Not sure what to do about it :( | 15:02.24 |
| | I'm more worried about how the right hand border has moved. | 15:05.09 |
| HenryStiles | Robin_Watts: I've always been suspicious of the offset approach... if the offset is can't be done on many devices the raster has to be moved. | 15:05.19 |
| | s/moved/translated | 15:05.37 |
| Robin_Watts | I think I'm going to leave the code as is at the moment. | 15:05.55 |
| HenryStiles | Robin_Watts: okay maybe a bug to look at in the future? | 15:06.11 |
| Robin_Watts | It'll need to be tweaked a bit when tkamppeters filter work happens. | 15:06.29 |
| | Probably by having the pcl_options have a structure to set offsets etc. | 15:06.49 |
| | Next thing to do is to make pcl output work with banding | 15:07.56 |
| HenryStiles | some work was done on this a long time ago by peter with the program align.ps .. you use that to determined the device margins then us ghostscript parameters to adjust the image. The documentation is in lib/align.ps ... I think we should using something like that and an equivalent in mupdf and not use offsets | 15:08.57 |
| | bbiab | 15:10.25 |
| Robin_Watts | tor8: 2 more commits on robin/master | 17:16.20 |
| | marcosw1: You about ? | 17:36.29 |
| HenryStiles | tkamppeter: know anything about turning off the screen in ubuntu, if I use the timer they go off for about 30 seconds then come back on. 3 monitors hdmi, dual and vga. I googled but didn't see anything, thought you might know. | 17:40.17 |
| | I mean setting the "inactivity timer" | 17:40.58 |
| | s/dual/dvi | 17:42.03 |
| Robin_Watts | HenryStiles: You mean that your screen saver is cancelling itself after 30 seconds? | 17:42.18 |
| HenryStiles | Robin_Watts: not really screen saver, it looks like the screen is turned off in the brief amount of time I've seen it in action | 17:43.54 |
| Robin_Watts | I've seen systems before where when you're detected as inactive, it starts a "screen saver" (pretty thing). After a while it then goes and actually shuts down the screens to black. | 17:45.14 |
| HenryStiles | screen saver doesn't reduce power right? It displays something possibly black, maybe I'm quibbling | 17:45.31 |
| Robin_Watts | HenryStiles: Right. That's why the pretty ones run for a while, and then go to black after a while. | 17:45.56 |
| | I'm wondering if your config is screwed up and it's getting confused about when it should run which. | 17:46.15 |
| | sebras: Were those bmps for private or public consumption? | 17:47.50 |
| | (i.e. do I add them to tests.git or tests_private.git ?) | 17:48.03 |
| malc_ | HenryStiles: man xset (dpms section) | 17:51.16 |
| HenryStiles | malc_: yea I can reproduce the same behavior with xset, it goes off for several seconds than comes back | 17:52.44 |
| malc_ | HenryStiles: try (xset dpms on; sleep 2) so that key-release event doesn't trigger anything | 17:53.24 |
| Robin_Watts | HenryStiles: I'd be tempted to sleep 60 and then unplug your keyboard and mouse. | 17:55.40 |
| | just in case either are sending spurious events. | 17:55.53 |
| malc_ | HenryStiles: and if you want to be brutal | 17:56.25 |
| | xrandr ââoutput HDMI2 ââoff | 17:56.31 |
| | for instance | 17:56.32 |
| HenryStiles | malc_: yup the sleep 2 did the trick. Be nice if they fixed it ubuntu system settings | 17:57.28 |
| malc_ | "Be nice"? I'm not nice enough? or should it have been parsed as "would have been nice"? | 17:58.21 |
| | not a native speaker you know, easily puzzled by those kind of things | 17:58.45 |
| Robin_Watts | "It would be nice if they fixed it" | 17:58.58 |
| HenryStiles | malc_: no thank yo for your help. I meant it would be nice if Ubuntu fixed their system settings | 17:59.09 |
| malc_ | HenryStiles: gotcha, you are welcome | 17:59.22 |
| | that said... "thank yo"? okay... you guys from the big island know better | 18:01.15 |
| HenryStiles | s/yo/you | 18:01.52 |
| | typo | 18:01.57 |
| malc_ | HenryStiles: http://bash.org/?5300 | 18:02.25 |
| HenryStiles | ;-) | 18:03.00 |
| rayjj | Robin_Watts: there is some small improvement on the 1-bit mono case, the most on PLRM_100 72.9->88.2 ppm | 18:08.34 |
| | mvrhel_laptop: I'll let you know when the mupdf numbers are all updated (this afternoon -- it takes a while to run) | 18:09.22 |
| Robin_Watts | rayjj: Right. PLRM_100 is largely white, so the short circuit check will help with that. | 18:09.23 |
| mvrhel_laptop | rayjj: ok unfortunately miles is going to print the numbers we have now | 18:09.48 |
| rayjj | mvrhel_laptop: now, now or now, real soon now ? The mono 1-bit case is almost done | 18:10.25 |
| mvrhel_laptop | I was going to send him the data in 15 minutes | 18:10.39 |
| | just got off the phone with him | 18:10.43 |
| rayjj | mvrhel_laptop: that should be enough for me to get the mono case updated | 18:11.02 |
| mvrhel_laptop | rayjj: ok | 18:11.11 |
| rayjj | starts editing the twiki... | 18:11.23 |
| | mvrhel_laptop: OK, new monochrome numbers are in. | 18:21.21 |
| mvrhel_laptop | rayjj: ok. thanks! | 18:23.40 |
| rayjj | I'll let you know when the cmyk numbers are in, but that won't be until after Miles has finished I guess | 18:24.18 |
| mvrhel_laptop | rayjj: I have to head out now. pick up dry cleaning etc | 18:30.28 |
| rayjj | the mono 1-bit numbers are probably more important than CMYK. The two most likely are mono and RGB contone, IMHO | 18:30.29 |
| mvrhel_laptop | yes | 18:30.34 |
| rayjj | mvrhel_laptop: Have a good trip | 18:30.43 |
| mvrhel_laptop | thanks | 18:30.45 |
| Robin_Watts | mvrhel_laptop: Have fun. | 18:31.37 |
| rayjj | Robin_Watts: starting cmyk next, then pkm | 18:32.55 |
| Robin_Watts | tor8: I'm just adding bmps to the cluster. Are there some epubs while I'm at it ? | 18:39.16 |
| | sebras: I've added a load of bmps to the cluster. Your ones, plus my ones, plus a load from SOs test suite. | 18:44.45 |
| | Some of them are showing issues. | 18:45.03 |
| | I added a single test epub to the cluster, and it's showing problems :( | 19:00.27 |
| rayjj | Robin_Watts: Before I update the CMYK numbers, the PLRM for contone CMYK *dropped* in performance slightly. 144.5->139.2 (600 dpi) and 41.1->39.1 (1200 dpi) | 19:52.07 |
| | I sort of expected "white skipping" to have helped on that file, but wasn't sure if that was done for CMYK | 19:53.16 |
| | BTW, did you see my comment last night about the large RAM "Peak" usage on j12_acrobat.pdf ? | 19:54.36 |
| | one thing we will have to tackle before using mupdf in a printer environment that has memory constraints is better automatic banding, particularly on pages with transparency, but j12_acrobat.pdf doesn't use transparency and has peak RAM at 100M when gs uses less than 48 (with similar band heights) | 19:55.30 |
| | when I use a script to have mutool draw run page by page on j12, any single page is less than 50Mb, but the peak memory for all pages is > 100Mb. Doesn't sound right | 19:55.31 |
| sebras | robin: public consumption as they come from gpl testsuites where the results are in thr public domain i think. | 20:01.50 |
| rayjj | Robin_Watts: the PKM is better across the board, including PLRM 29.2->39.5 @600dpi | 20:03.11 |
| | Robin_Watts: nm, I guess "white skipping" doesn't relate to CMYK contone (only to skipping halftoning). Sorry. As far as why CMYK performance went down, maybe my Pi is getting tired ? | 20:05.06 |
| sebras | robin: you will need to teach me how to find the problematic bmps. oh and over at sebras/master are a few fixes for mslc's bmp issues | 20:05.39 |
| | robin: you already reviewed them! the intent was to extend the web palette from 216 to 256 entries. | 20:08.56 |
| malc_ | sebras: just when i wanted to say god påske you started throwing names around... mslc.. yeah right | 20:09.21 |
| sebras | robin: i must validate that readcolors is clamped | 20:09.35 |
| | malc_: im on mobile. | 20:10.12 |
| malc_ | sebras: lamest excuse ever, or maybe not, never owned a mobile device so wouldn't know | 20:12.36 |
| Robin_Watts | sebras: I reckon it's clamped to 256 :) | 20:34.34 |
| | rayjj: I did see that. I had nothing to add so I said nothing, but I agree. | 20:35.33 |
| sebras | Robin_Watts: do you mind teaching me how to see the issues you mentioned? | 20:35.52 |
| Robin_Watts | white skipping doesn't apply to cmyk, no, just to halftoning. | 20:36.24 |
| | So I can't say why it got slower - but it's not much slower. | 20:36.37 |
| | sebras: Sure. | 20:36.59 |
| | We've got you set up on the cluster, right? | 20:37.07 |
| rayjj | Robin_Watts: not sure if memento can help us track "stale" allocations with some kind of call between pages. It probably can (it does everything else :-) ) | 20:37.23 |
| Robin_Watts | rayjj: We can tell it to list all the blocks, and then later all the 'new' blocks. | 20:37.51 |
| rayjj | Robin_Watts: not a lot slower | 20:37.53 |
| sebras | Robin_Watts: I think so, but i may have lost my password. | 20:38.30 |
| Robin_Watts | sebras: OK, that would be a problem :) | 20:38.49 |
| rayjj | Oh, it keeps track of blocks it has listed. I figured a "list all blocks" after each page and then compare to look for new stuff, but if it can tag blocks it already listed, that's even better | 20:39.28 |
| | Forward 1 day (to 2016/03/26)>>> | |
IRC Logs