| | <<<Back 1 day (to 2013/10/02) | 2013/10/03 |
| ray_laptop | mvrhel_laptop: question: If the background is being painted "white" with pdf14 transparency, is it OK to skip it (alpha == 1.0 color == white, no non-white painting done) | 02:51.03 |
| | Robin_Watts: (for the logs) this file paints a letter size rectangle as white *TWICE* at the start of the page !!! When using the ASIC, it's no big deal, but the 6thgen doesn't have an ASIC and the poor PPC has to do this THREE times per band. | 03:07.06 |
| | (once with fillpage, then twice more -- just to make sure it's really white) | 03:07.28 |
| | Also, the pdf14 device ends up marking a much larger region as "dirty" because it was written with white | 03:08.11 |
| | thus my query for mvrhel_laptop above | 03:08.25 |
| | hmm... it seems that the pdf14 code they (cust 532) are using does not track the 'dirty' rectangle, so that's another possible optimization -- porting over from the HEAD code | 03:13.50 |
| | Robin_Watts: I'm going to send you a git patch with the logic added to skip the extra initial write white actions. Please give it a try on your performance analyzer, although an modern x86 may be a LOT better at filling memory with white than their CPU | 03:15.40 |
| | oops. I just realized I pushed my fixes for saved-pages mode without review. Robin_Watts, chrisl_away, or anyone else, please review (just in case) | 03:43.01 |
| mvrhel_laptop | ray_laptop: sorry I missed you | 05:06.55 |
| | I am in the middle of this knockout / softmask issue. | 05:07.06 |
| | hopefully the last part of this mess | 05:07.16 |
| | I do some places where the background initialization could use some clean-up. | 05:07.50 |
| | the down side is that with this fix the background stuff is a little more complex, so there may be two parts to this. | 05:08.16 |
| | one where I commit my fix for all these knockout changes and then a commit for some optimizations | 05:08.40 |
| | I am hoping that you and Robin don't do to many changes in the pdf14 code right now. | 05:08.57 |
| | My changes in are fairly extensive | 05:09.09 |
| | I am hoping to have them in place by this weekend | 05:09.19 |
| | perhaps you can avoid putting anything in head until then | 05:09.38 |
| | found my issue so I am calling it a night. see you all friday | 05:09.56 |
| chrisl | ray_laptop: (for the logs) your saved-pages commit seems good to me | 08:43.57 |
| kens | Well, the first problem with 16-09.ps is the same as yesterday, it has an override in the Metrics for the left side-bearing and we aren't applying it to either writing mode..... That eliminates the rendering problems | 08:56.11 |
| Robin_Watts | http://www.theonion.com/video/new-apple-friend-bar-gives-customers-someone-to-ta,17693/ | 09:16.00 |
| | Hmm. | 12:41.33 |
| | gx_color_index is defined as a 64bit type for customer 532s device. | 12:42.01 |
| | Given that it's a mono printer, it's never going to handle that many colors. And I bet powerpc struggles a bit with 64bit ints. | 12:42.29 |
| | I wonder if it's worth redefining it as a 32bit type ? | 12:42.41 |
| kens | You can certainly try | 12:42.58 |
| | Presumably you will have to test it on target though | 12:43.10 |
| Robin_Watts | yes. Was just wondering if any of you could think of an immediate reason why it'd be bad. | 12:44.38 |
| kens | drestricted colours is all I cna think of | 12:44.49 |
| Robin_Watts | restricted colors ? | 12:45.48 |
| kens | Doens't the index limit the maximum colours (inks) avilable ? | 12:54.47 |
| Robin_Watts | kens: It does. | 12:55.00 |
| | but this is a mono printer. | 12:55.07 |
| kens | Yes, so not a problem. | 12:55.15 |
| Robin_Watts | right. | 12:55.19 |
| | lunch. | 12:55.37 |
| | gs bitmaps are always msb first, right? | 13:57.36 |
| | Morning mvrhel_laptop | 13:57.41 |
| kens | No idea Robin_Watts | 13:57.49 |
| | But I bleive this is normally the case | 13:57.59 |
| paulgardiner | tor7: another couple of commits on paulg/master if you have a moment. | 14:02.23 |
| | tor7: actually, I just want to change the name of some methods. | 14:09.55 |
| | tor7: sorted | 14:15.33 |
| Robin_Watts | Morning ray_laptop | 14:48.27 |
| ray_laptop | morning, Robin_Watts | 14:51.42 |
| | Robin_Watts: the email you sent with "Here is the profile" didn't have an attachment. | 14:52.40 |
| | Robin_Watts: changing to a 32-bit color index should be easy (trivial) | 14:53.17 |
| Robin_Watts | resent. | 14:53.28 |
| | ray_laptop: I've got my head up ktd2bit_fast_copy_mono at the moment. | 14:54.02 |
| ray_laptop | Robin_Watts: I had looked at that a while ago. The default was faster since it handles runs of the same color, but you might have other methods than what I had tried (a couple of years ago) | 14:55.37 |
| Robin_Watts | ray_laptop: My plan is to read bytes in, and look them up to give shorts. | 14:56.25 |
| | Then those can be masked into the output. | 14:56.48 |
| | that should cope with the black/transparent, white/transparent, black/white cases efficiently. Anything else can fall back to the default. | 14:57.21 |
| | but the endian issues are screwing with my head at the moment. | 14:58.04 |
| ray_laptop | Robin_Watts: OK, so anything that needs painting from the halftone tiles can use the default. | 14:58.12 |
| Robin_Watts | ray_laptop: Right. | 14:58.20 |
| ray_laptop | Robin_Watts: that approach to optimizing B & W should be better. | 14:59.03 |
| | Robin_Watts: it looks like the fast_fill_rectangle went down from the previous performance report (from 7.14 to 5.52). I can only guess that is due to skipping the extra initial white fills | 15:04.34 |
| Robin_Watts | ray_laptop: yeah. | 15:05.33 |
| ray_laptop | Robin_Watts: strangely art_pdf_composite_pixel_alpha_8_fast_mono went from 3.99 to 5.38 | 15:05.34 |
| | I have to take my son to school. bbiab | 15:05.55 |
| | ok, I'm back | 15:40.02 |
| | Robin_Watts: so thinking about the pdf14 issue, painting to the 2bit device for all of the copy_mono (text) that doesn't have transparency, and only doing the pdf14 on the part with the image would be a win | 15:42.20 |
| Robin_Watts | indeed. | 15:42.37 |
| ray_laptop | we know the bbox. The slightly tricky thing is having the pdf14 device operate in 'pass through' mode for elements outside the bbox. | 15:43.17 |
| Robin_Watts | ray_laptop: foolishly, I thought we did that already. | 15:43.40 |
| ray_laptop | the *really* tricky part is handling any objects which overlap the edge of the bbox | 15:43.45 |
| | Robin_Watts: right now, because of those two issues, we just skip the pdf14 compositor actions for the entire band if there is no need for transparency (i.e., painted only with alpha == 1.0) | 15:45.02 |
| Robin_Watts | ray_laptop: In this case, it's not alpha, it's the presence of a softmask. | 15:45.34 |
| ray_laptop | I went ahead an put if code to track the x-coords of the transparency box | 15:45.40 |
| | Robin_Watts: right. For SMask, I assume that somewhere there will be a need for transparency (not an entirely opaque SMask) | 15:46.38 |
| | I'm quite reticent to try and tackle that now, on a rush project, but maybe that's the only way I'll actually do it :-/ | 15:49.02 |
| Robin_Watts | ray_laptop: It sounds like a biggish job, yes. | 15:49.53 |
| ray_laptop | I'm wondering if knowing where the pdf14 buffer is just black and white vs, needs halftoning, would allow us to optimize the 'put_image' | 15:50.43 |
| | converting a rectangle of black and white 8-bit to 2-bit can be optimized quite a bit, I would think | 15:51.32 |
| Robin_Watts | currently ktd2bit_put_image just calls copy_color. | 15:53.25 |
| ray_laptop | so, having the pdf14 device maintain a bbox of 'has_gray_shade' for the buffer should be fairly easy when flattening the alpha for the put_image | 15:53.33 |
| Robin_Watts | but it's only 1.25% in my profile. | 15:53.47 |
| ray_laptop | Robin_Watts: I see. So not much "fluff" in that | 15:54.07 |
| Robin_Watts | well, potentially lots of fluff. Just not much space gained by clearing the fluff out :) | 15:54.28 |
| ray_laptop | Robin_Watts: so, from your performance analyzer results, how much savings do you think I should suggest to Len from optimizing the initial white fills away | 15:56.48 |
| | I see the numbers 7.14 to 5.52, but don't know how much that represents | 15:57.30 |
| Robin_Watts | ray_laptop: I wouldn't like to put a number on it. | 15:57.55 |
| | It looks to me like the gs stuff is roughly 50% of that profile. | 15:58.25 |
| | andn you've saved 1.5 of that 50. | 15:58.41 |
| | So about 3% overall, maybe ? | 15:58.51 |
| | Total time for this job was 25 seconds or something? | 15:59.14 |
| | 26 seconds. | 15:59.38 |
| | so 3% of 26 = 0.75 seconds at a guess? | 15:59.58 |
| | but I suspect that the powerpc has a much poorer cache than PCs, so it might be a lot more. | 16:00.16 |
| | Only way is to suck it and see, I think. | 16:00.28 |
| | I'm stuck in endian hell here - do you want to try the gx_color_index to 32bits thing? or tell Len how to try it on the target? | 16:01.23 |
| ray_laptop | the gs_start inclusive time has a number "55.01" -- how does that relate to 26 seconds ? | 16:01.26 |
| | Robin_Watts: I'll do the 32-bit color index change, yes | 16:01.46 |
| | Robin_Watts: we don't ever carry around large buffers of color_index info, so I don't expect much, but who knows | 16:03.16 |
| Robin_Watts | it's a cost on every function call that takes one. | 16:03.33 |
| | and a cost on every compare. | 16:03.40 |
| | I don't expect it to get us seconds in the results though. | 16:04.04 |
| | I can't help feeling that memset would be better in ktd2bit_fillpage too. | 16:09.46 |
| ray_laptop | Robin_Watts: so pdf14 still is a big hit -- the mark_fill_rectangle is 7.36, 5.15 of that in the art_pdf_composite... and the pdf14_compose_group_inner is 4.79 calling the art_pdf_composite for EVERY pixel painted always seemed like a waste, particularly when the alpha is 1 | 16:10.29 |
| Robin_Watts | Yes. | 16:11.16 |
| ray_laptop | Robin_Watts: it probably would. It (sort of) bends the "rules" for accessing the buffer to fill a big block without getting the scan_line_base for each line, but ... | 16:11.42 |
| Robin_Watts | I tried pulling art_pdf_composite... into the same file and making it a static inline so it would get optimised | 16:11.48 |
| | ray_laptop: No, I meant still get the scan_line_base. | 16:12.02 |
| ray_laptop | I see, so just memset the line | 16:12.24 |
| Robin_Watts | I like to think that memset should be optimised more than the C compiler can manage a simple loop on a line. | 16:12.32 |
| ray_laptop | you are probably right. It's easy enough to try. | 16:12.55 |
| | OK, I'm going to work on the color index. In the meantime, I'll push Len to make sure he is trying the initial white optimization | 16:14.06 |
| Robin_Watts | Hmm. I just ran my changed code, and it didn't crash. | 16:14.47 |
| | and the output looks right. | 16:14.51 |
| | Something must be wrong. This can NOT have worked first time. | 16:15.02 |
| | Right. The code isn't getting called :) | 16:15.46 |
| | now the code is being called and the text is garbled. better :) | 16:18.45 |
| ray_laptop | that's better ??? | 16:18.57 |
| | ;-) | 16:19.13 |
| Robin_Watts | ray_laptop: Now I just need to fix my code. | 16:19.13 |
| | A simple matter of programming. | 16:19.22 |
| | Woo Hoo! recognisable text. | 17:06.27 |
| kens | :) | 17:09.52 |
| | OK goodnight all | 17:28.30 |
| Robin_Watts | ray_laptop: ping | 17:43.04 |
| ray_laptop | Robin_Watts: pong | 17:45.55 |
| Robin_Watts | So I sent my copy_mono patch off. | 17:46.08 |
| | currently it only does the 'black on transparent' case, as that's the only one that this file exercises. | 17:46.35 |
| | So, what ideas do we have left? | 17:46.48 |
| ray_laptop | Robin_Watts: right -- Len wanted the entire file. Can you do that ? | 17:46.51 |
| Robin_Watts | ray_laptop: Sure. | 17:47.01 |
| ray_laptop | Robin_Watts: I still haven't had a chance to try the 32-bit color_index change | 17:47.32 |
| Robin_Watts | ray_laptop: Shall I have a look at that then? | 17:48.01 |
| henrys | ray_laptop:just sent you an email - I have a customer meeting tomorrow, so if you can answer today that would help. | 17:50.18 |
| ray_laptop | Robin_Watts: The other thing I thought of was tracking the 'is_marked_with_non-white' in pdf14 so we can skip the initial white writes on that page as well | 17:53.43 |
| | Robin_Watts: on the phone with Len. Does the file already have the white optimization changes in it? | 17:59.37 |
| Robin_Watts | ray_laptop: It has the last patch you sent me, yes. | 18:00.00 |
| | Attempt optimization by reducing large area background painting. <- that one. | 18:00.28 |
| ray_laptop | yes | 18:00.37 |
| | Robin_Watts: OK. I will send him the gxclrect part of that patch | 18:02.50 |
| Robin_Watts | ray_laptop: Oh, ok, sorry, I assumed he'd got that. | 18:03.19 |
| ray_laptop | Robin_Watts: no problem. He has it now. | 18:05.01 |
| | Len is building now. He'll let us know as soon as he has timings | 18:05.36 |
| | henrys (for the logs): I'll get a list of printers from Len (the ones that are shipping). They have a whole bunch (about 5) new printers in development now. | 18:08.02 |
| | Robin_Watts: I looked at debugobj/arch.h and it has: #define ARCH_SIZEOF_GX_COLOR_INDEX 4 | 18:50.31 |
| | Robin_Watts: so I think it should already be running with 32-bit color_index | 18:51.13 |
| Robin_Watts | ray_laptop: I just sent a makefile change to Len. | 18:51.23 |
| | without that change, I was getting 64bit values in the debugger. | 18:51.34 |
| ray_laptop | also the typedef (according to VS says it is ulong) | 18:51.36 |
| | Robin_Watts: on private... | 18:52.11 |
| Robin_Watts | ray_laptop: VS doesn't pick up the fact that the makefile does /DGX_THINGY_TYPE= | 18:52.40 |
| | Currently their device is providing map_rgb_color rather than encode_color. | 18:55.11 |
| ray_laptop | Robin_Watts: I'll tell Len about updating their target Makefile | 18:55.21 |
| Robin_Watts | This is making it use backward compatible stuff to go grey mapping. | 18:55.32 |
| | I'm gonna have a crack at a proper encode_color/decode_color for them that might shave a bit off. | 18:55.55 |
| ray_laptop | Robin_Watts: oh, that's another layer in the remap call sequence | 18:56.04 |
| Robin_Watts | dev->color_info.num_components is always going to be 1 for them, right? | 18:57.11 |
| ray_laptop | Robin_Watts: only for the 6thgen devices | 19:12.25 |
| | but that's all that's in that file | 19:12.54 |
| | henrys: I think most of the printers we are in are fairly "beefy". The 6thgen is the lowest level one. I've asked Len what the model number(s) are for that. It doesn't have a disk, and no GEU ASIC (so we do the rendering) | 19:22.08 |
| henrys | ray_laptop: thanks for asking him. | 19:26.26 |
| ray_laptop | np | 19:26.31 |
| henrys | bbiab | 19:26.50 |
| ray_laptop | me, too. bbiab | 19:31.13 |
| | yet another errand :-( | 21:43.24 |
| | at least I got some work in :-) | 21:43.47 |
| Micha` | Hey people! Any MuPDF dev around here? | 23:07.18 |
| Robin_Watts | Micha: yes, but just going to bed. | 23:09.28 |
| | be quick, or try back in the morning... | 23:10.16 |
| Micha` | Ah! This is a quicky; it seems like the subscription to the ghostscript bug tracker is on a slow pace tonight, and I'm pretty sure I'll have forgotten this next morning. | 23:10.26 |
| | In mupdf.c, in Android JNI, there is a missing (*env)->DeleteLocalRef(env, pt); | 23:10.43 |
| | There. | 23:10.45 |
| | Everything is said. | 23:10.49 |
| | Except the line, maybe. This is line 1545. | 23:11.03 |
| Robin_Watts | Micha`: Where in mupdf.c ? Ah. Thanks. | 23:11.08 |
| | deleting refs is generally not required. | 23:11.25 |
| Micha` | Basically, any ink annotation bigger than 512 points makes muPDF crash. | 23:11.46 |
| Robin_Watts | Ah, in a loop. Yes, you're right, thanks. | 23:12.04 |
| Micha` | I guess not when java has a chance to GC, but within a loop? | 23:12.07 |
| Robin_Watts | I suspect we need a free for the arc's too. | 23:12.59 |
| Micha` | Ah, no problem. This is my first time getting into either java or mobile device dev, so I could have been pretty far from anything relevant. | 23:13.20 |
| Robin_Watts | Thanks for the report. I'll try to get them into the repo tomorrow. | 23:13.35 |
| Micha` | Ah, yes, yes, that's right, but they were way fewer in my tests :-) | 23:13.42 |
| | No problem, thanks for the reaction time :) | 23:14.10 |
| Robin_Watts | np. | 23:14.14 |
| | ray_laptop: For the logs: The transparency thing I just found seems to be saving 10% overall (using the same fuzzy maths as before). Let's hope anyway. | 23:22.53 |
| | Forward 1 day (to 2013/10/04)>>> | |
IRC Logs