| | <<<Back 1 day (to 2013/11/10) | 2013/11/11 |
| Robin_Watts | hi ray | 00:43.46 |
| mvrhel_laptop | 6,038,190 vs 19 sounds like something went terribly wrong someplace | 00:53.17 |
| Robin_Watts | 6,038,190 = number of lookups of a link. 19 = number that the cache couldn't satisfy? | 00:58.37 |
| mvrhel_laptop | oh ok | 00:58.54 |
| Robin_Watts | That sounds like the cache is doing rather well. | 00:58.54 |
| mvrhel_laptop | yes. I misunderstood | 00:59.01 |
| Robin_Watts | I'm guessing... | 00:59.01 |
| mvrhel_laptop | that makes a lot more sense | 00:59.12 |
| | I was reading that with NRT=1 he was getting 19 | 00:59.31 |
| Robin_Watts | I've been slightly sidetracked by something else. I hope to get to the persistent cache in the next couple of days. | 00:59.49 |
| mvrhel_laptop | and with NRT Not = 1 he was getting 6,038,190 | 00:59.50 |
| Robin_Watts | bedtime for me. | 00:59.53 |
| | mvrhel_laptop: Right. I agree that that's a misreading of it. | 01:00.09 |
| | night. | 01:00.16 |
| mvrhel_laptop | Robin_Watts: ok goodnight. if you get a chance to look at my commit in my repos for mupdf much appreciated | 01:00.17 |
| Robin_Watts | I will look tomorrow. | 01:00.27 |
| mvrhel_laptop | yes thanks | 01:00.34 |
| Robin_Watts | np. | 01:00.38 |
| ray_laptop | Robin_Watts: (for the logs). Can you build my code an try it on your machine that you had used for previous timings to see if you see similar relative performance. I'm curious to see how much overall gain we've had since the code we got from them, but I can't run their original device. | 07:36.49 |
| | Robin_Watts: (FTL): if it is much work, then don't bother. | 07:37.08 |
| | Robin_Watts: in an attempt to determine how much persistent ICC cache might save us, I was going to modify the 'process_page' to take a num_copies so that we can process the page multiple times with the same set of threads. It also takes away the setup/teardown but if the ICC cache is a big hit, it might tell us something | 07:40.03 |
| | but if you want to just do the persistent cache and time it, fine. | 07:40.36 |
| | kens: your response to that (not very reasonable) request to "substitute all fonts" was informative, and I will keep it around to send out on occasion. Most people have *NO IDEA* what is involved in fonts, and this helps explain it a bit. | 08:47.29 |
| | kens: you were certainly more helpful than I would have been :-) | 08:47.51 |
| | kens: although I doubt the sender will know enough to understand even the surface of your response "IT IS NOT POSSIBLE" is what I would have said :-) | 08:48.53 |
| | but maybe since he had read enough about it to discover that there was a Fontmap.gs may prove me wrong. | 08:50.09 |
| | I hope this doesn't end up like that other free PITA user we had recently | 08:50.35 |
| | I was *seriously* considering killing him from ever being on this channel | 08:51.23 |
| | (I probably would have if I could have remembered the commands to do it ;-) ) | 08:51.55 |
| | time for bed. bbiaw.... | 08:52.27 |
| ray_laptop | snores, not so softly... | 08:52.36 |
| kens | For the logs, sorry Ray I was getting a coffee.... | 08:59.27 |
| Amnesia | are there any mupdf devs as we speak? | 09:11.03 |
| kens | Amnesia : Bit early, another hour or so would be better | 09:11.20 |
| Amnesia | if so, how can I prevent my android tablet from dimming out after a while? | 09:11.21 |
| | ah ok, ty | 09:11.26 |
| kens | Amnesia : I'm not an expert, butthat sounds more like an Android thing thatn MuPDF | 09:11.45 |
| Amnesia | hm, well I guess an app should be able to override the default behaviour right? | 09:12.10 |
| kens | SOrry, no idea. I'm neither an Android developer nor a MuPDF one | 09:12.27 |
| | But if its battery saving related it may not be possible to override | 09:12.49 |
| Robin_Watts | Amnesia: AIUI there are Android hooks that we could call to defeat the screen saver. | 09:13.21 |
| | but to do so would be risky. | 09:13.34 |
| kens | thinks Robin_Watts is up and about early | 09:13.50 |
| Amnesia | but then how do you read stuff on it:P? | 09:13.52 |
| Robin_Watts | Certainly we'd need a configuration option, we couldn't do it by default. | 09:13.56 |
| kens | Well if this is a screen saver, tehn any action will prevent it kicking in, so read fasterand scroll down :-) | 09:14.46 |
| | Or alternatively, change the screen saver settings ? | 09:14.57 |
| | And another 7.5 year old bug closed..... | 09:15.44 |
| Amnesia | Robin_Watts: it it on the roadmap or not? | 09:16.51 |
| kens | Amnesia : I think its fair to assume its not, since nobody has ever requested such a thing. If you want it considered I would advise opening a bug report and setting it to 'enhancement' | 09:18.12 |
| Amnesia | hmkay, ty:) | 09:18.39 |
| | may I ask what app you use for ebooks/pdfs? | 09:18.57 |
| | (if you've got an android^^) | 09:19.02 |
| kens | I don't have an android device, my wife has a Nexus tablet, I don't know what she uses though.... | 09:19.22 |
| | And I use a variety of apps on Windows and Linux to read PDF files | 09:19.39 |
| Amnesia | hmkay, ty | 09:19.57 |
| tor7 | paulgardiner: ping. | 13:45.20 |
| paulgardiner | tor7: hi | 13:45.45 |
| tor7 | in pdf_load_builtin_font you calculate fontdesc->ascent, but you haven't added the same lines to pdf_load_substitute_font. any specific reason? | 13:45.59 |
| paulgardiner | I can't remember, but my guess is that I added the minimum I needed for producing freetext annotations. We support only built-in fonts for the pdf device at the moment. | 13:51.36 |
| | So no good reason AFAIK :-) | 13:51.49 |
| | Strange coincidence I was thinking about that area of code yesterday. We still need to solve the problem of reusing fonts from a pdf document within the pdf device. Otherwise I can't swap my old form-widget appearance-stream creation code (that just hacks strings) over to using the pdf device. | 13:55.32 |
| tor7 | paulgardiner: I'm also seeing spurious error messages "error: invalid page object" when running through pdfref13.pdf which I think may be related to something you've done :) | 14:15.03 |
| | I think the fz_font struct and loading code is in need of a good overhaul soon. | 14:15.39 |
| | it's getting rather hairy to keep track of all the details... | 14:15.51 |
| paulgardiner | I did very little within the font system. It shouldn't be hard to track down the changes. | 14:16.23 |
| tor7 | my complaint is not related to your stuff, it's just that the complexity has grown over the years and no real architecture has formed around it. organic mess. :( | 14:17.25 |
| | and if we're now aiming to use it for more and more stuff, we really ought to think long and hard about what needs to be where | 14:17.55 |
| paulgardiner | Not an unusual situation to arise IME. Thankfully, MuPDF is one of the few projects that goes back and sorts out that type of thing. | 14:18.52 |
| henrys | US holiday today | 14:19.52 |
| paulgardiner | If fz_font were to be overhauled, it would be handy if one could tell that a fz_font came from interpretation of a pdf doc and recreate some of objects from that document - useful for appearance-stream synthesis at least. | 14:20.23 |
| | henrys: Okay. Don't worry about us. We'll soldier on relentlessly - fingers to the bone - while you laze about all day. :-) | 14:26.57 |
| henrys | soldier on is perfect - it's veterans day here . | 14:28.19 |
| paulgardiner | Oh right. Nice one. :-) | 14:28.42 |
| Robin_Watts | henrys: Yes, it's remembrance day here. | 14:37.58 |
| henrys | Robin_Watts: ah but folks usually work⦠banks open and such? | 14:41.33 |
| Robin_Watts | yes, it's not a bank holiday. | 14:41.55 |
| tor7 | paulgardiner: Robin_Watts: a handful of commits on tor/master waiting for review | 15:15.53 |
| Robin_Watts | tor7: ah, yes, and I must lookat mvrhel's too. | 15:16.10 |
| | fz_new_buffer_from_data. | 15:18.02 |
| | or fz_new_buffer_with_data ? | 15:18.10 |
| | _with_ doesn't seem to pass ownership in. _from_ therefore sounds better to me. | 15:19.52 |
| | actually, that's not true. | 15:20.56 |
| | fz_open_document_with_stream passes the ownership in. | 15:21.17 |
| tor7 | Robin_Watts: yeah, we don't have a clear naming there for ownership passing | 15:25.11 |
| | btw, don't push the fontconfig one, I want to keep that on a separate branch since I am *not* willing to support that in the mainline distribution | 15:25.41 |
| Robin_Watts | tor7: In the last one... | 15:25.47 |
| | If you make buf = NULL at the top, and fz_var(buf) | 15:26.33 |
| | then you can put the fz_warn into the fz_catch | 15:26.41 |
| | and the dedicated error handling section can roll into the normal exit. | 15:27.03 |
| | neater IMHO. | 15:27.31 |
| | Otherwise, all fine. | 15:27.37 |
| tor7 | I want the warn on all error exits, though. not just in the catch case | 15:27.46 |
| Robin_Watts | So put the error: in the catch block. | 15:28.01 |
| tor7 | I could roll the normal into the error and only warn if (!buf( | 15:28.03 |
| | Robin_Watts: like in the latest commit on tor/master now? | 15:30.12 |
| Robin_Watts | mvrhel has a directX printing review on his repo. It looks plausible to me, but I don't have the energy to read it all in detail (and I wouldn't understand it if I did). | 15:30.52 |
| | Anyone else want to look before I just nod it through? | 15:31.05 |
| tor7 | mvrhel triple-spaces after periods in his git commit messages... I find that oddly disturbing :) | 15:31.23 |
| Robin_Watts | tor7: personally, I'd have done: fz_catch(ctx) { error: fz_warn(); } ... | 15:32.06 |
| | but what you have is fine. | 15:32.26 |
| tor7 | it's hairy enough to remember the scoping rules for try/always/catch without adding gotos and labes into the mix :) | 15:32.34 |
| | Robin_Watts: then I shall push all but the fontconfig stuff to master (and the fontconfig on a 'fontconfig' branch) | 15:33.01 |
| | if it didn't add such a big mess to the makefile I'd be happier :( | 15:33.28 |
| Robin_Watts | henrys: Are you about for a quick skype? | 16:04.41 |
| kens | Its a US holiday | 16:05.34 |
| ray_laptop | morning, all | 16:09.31 |
| kens | Morning ray_laptop sorry I missed you in my morning | 16:09.43 |
| ray_laptop | kens: no problem. It wasn't important, but I did like the clarity of your response :-) | 16:10.16 |
| kens | Its a complex area, I'msure he won;t understand :-( | 16:10.36 |
| Robin_Watts | kens: yeah, and he's probably still unpacking. | 16:11.18 |
| ray_laptop | Scott doesn't tend to filter requests from free users that come over the fence to 'sales' or 'info' | 16:11.30 |
| kens | henrys is I guess, yes | 16:11.35 |
| | ray_laptop : yes, that's why I asked him if it was a sales contact | 16:11.47 |
| chrisl | kens: It was a lot better than the "are you out of your mind?" response that was my first instinct..... | 16:11.53 |
| kens | ROFL | 16:12.02 |
| | It might have some sense in a tightly cvontrolled workflow, but in that case, use the correct font to start with.... | 16:12.33 |
| | Nice to hear something from Marti RObin | 16:13.25 |
| Robin_Watts | kens: yeah. I'd heard from henrys that it had been agreed and was moving, but had no idea how long Marti was going to take about it. | 16:16.23 |
| kens | Always nice to see something happening. | 16:16.41 |
| ray_laptop | Robin_Watts: did you see my comment / request about running the timing on your machine so they match up with what you posted on 11/6. Also note that I didn't bother testing 300 dpi modes, although maybe I should have. | 16:16.50 |
| henrys | yea I'll be here periodically | 16:16.52 |
| Robin_Watts | ray_laptop: I didn't, sorry. | 16:17.31 |
| henrys | 1 man month, 3 months - he's working part time | 16:17.48 |
| kens | So hopefully in time for our next release | 16:18.11 |
| ray_laptop | Robin_Watts: If you think it's important, I can easily enough run the 300 dpi cases | 16:18.16 |
| Robin_Watts | ray_laptop: I wouldn't bother. | 16:18.28 |
| ray_laptop | Robin_Watts: OK. | 16:18.38 |
| Robin_Watts | I think the main thing is that we've offered relative timings. | 16:18.40 |
| | They should now be in the position to do any timings they want. | 16:18.54 |
| henrys | kens:maybe so | 16:18.55 |
| ray_laptop | Robin_Watts: yes. hopefully they can do the real timings on a CPU they have | 16:19.15 |
| henrys | Robin_Watts: on skype | 16:19.38 |
| ray_laptop | IME, unfortunately, some printer companies have a hodge-podge of systems and aren't always careful in doing benchmarking (not this customer, though, AFAIK) | 16:20.44 |
| | I was pleasantly surprised that BGPrint had such an impressive impact on performance. Much better than selective plane skipping :-/ | 16:22.17 |
| | I have tried to do profiling, but VS 2008 'performance analyzer' leads immediately to a BSOD :-( Very sleepy "Launch" doesn't seem to work, and if I attach to a process, it merrily collects, then gets an error before displaying any results (after I hit "OK" to stop) | 16:32.15 |
| Robin_Watts | ray_laptop: VS2008's profiler worked for me. | 16:32.43 |
| | Sleepy is temperamental, sadly :( | 16:33.04 |
| | ray_laptop: So I'm looking into this persistent list of icc_cache's now. Question is where best to free them eventually... | 16:36.49 |
| | Devices tend to be page based things, right? opened at the start of a page, closed at the end. I want something that persists across multiple pages. | 16:39.16 |
| | I could use the gs_lib_ctx itself, but that would mean using the underlying malloc allocator for the gsicc stuff. | 16:39.48 |
| kens | Devices persist across pages | 16:39.51 |
| | THey are opened when selected, and closed when deselected | 16:40.06 |
| | No matter how many pages arrive in between | 16:40.17 |
| Robin_Watts | kens: Ah. | 16:40.42 |
| chrisl | They can also be closed and reopened when settings change..... | 16:40.53 |
| kens | Yes that's true | 16:41.00 |
| Robin_Watts | So maybe I should be putting the icc_list cache in the device rather than in the lib_ctx. | 16:41.14 |
| kens | And that (now) properly resets the count of pages too :-) | 16:41.17 |
| Robin_Watts | As long as that won't discard the cache because of unnecessary openings/closings. | 16:41.41 |
| ray_laptop | Robin_Watts: sorry. | 16:41.49 |
| kens | The open/close only occurs in response to setpagedevice | 16:41.57 |
| Robin_Watts | ray_laptop: No problem. | 16:42.03 |
| kens | Where we change device or its attributes | 16:42.07 |
| ray_laptop | Robin_Watts: they also should be freed when the prn_device closes | 16:42.13 |
| kens | I would think that if we change attributes of the device that would be a potential reason to discard the cache | 16:42.36 |
| Robin_Watts | ray_laptop: So you think that the device is the right place to hide these ? | 16:42.43 |
| ray_laptop | Robin_Watts: for BGPrint I had to add a 'wait for last page to finish' to prn_close | 16:42.53 |
| | Robin_Watts: for non-clist (not gx_device_printer) classes where there is a renderer that has its own cache, that's where its important, right | 16:44.27 |
| | otherwise the clist cache is the same as the parser class and is kept around, right ? | 16:45.02 |
| | s/parser class/parser cache/ | 16:45.15 |
| Robin_Watts | ray_laptop: The clist thread buffers are recreated for every page, right ? | 16:45.34 |
| ray_laptop | Robin_Watts: and if the NumRenderingThreads decreases, we can free ones that we no longer need, and similarly if we increase the NRT | 16:46.26 |
| | Robin_Watts: the thread buffers are created once, and freed at the end of the page | 16:46.59 |
| Robin_Watts | ray_laptop: Initially I am primarily interested in making it work for the numrenderingthreads case, but it should also work for the single threaded case | 16:47.54 |
| ray_laptop | Robin_Watts: and everything we are saying for the threads also applies to the BGPrint thread | 16:48.04 |
| Robin_Watts | hence putting it in the clist device would be bad. | 16:48.40 |
| ray_laptop | Robin_Watts: but if NRT=0 and BGPrint=false, then the rendering cache will be inherited from the parser (I am checking that, now) | 16:49.13 |
| Robin_Watts | So either in the prn device, or in the generic device would seem sensible. | 16:49.13 |
| | oh, so the cache is already carried across between pages in the NRT=0, BGPrint=false case? | 16:49.58 |
| | So then this IS just a clist thing. | 16:50.04 |
| ray_laptop | Robin_Watts: the icc_cache_cl is peculiar to the clist rendering, yes | 16:52.41 |
| Robin_Watts | No, I meant the NEW thing I want to add, the persistent list of icc_cache's | 16:53.15 |
| | If in the NRT=0 and BGPrint=false cases, the icc_cache is carried over between pages already, there is nothing for me fix there. | 16:53.52 |
| | The only place where we need to carry it over is when the clist is being used. | 16:54.16 |
| ray_laptop | Robin_Watts: the icc_link_cache is a member of the gs_imager_state | 16:55.14 |
| Robin_Watts | right, and for the num rendering threads case, we have to create a new imaging state out of nowhere, right? | 16:56.00 |
| ray_laptop | Robin_Watts: in clist playback_band it uses a new 'imager_state' and so it handles it differently (see lines 609..) | 16:57.07 |
| Robin_Watts | and it gets the icc_link_cache from cdev->icc_cache_cl | 16:58.34 |
| ray_laptop | Robin_Watts: right, that's how it gets preserved across band, AIUI | 17:00.11 |
| Robin_Watts | ray_laptop: Absolutely. | 17:00.25 |
| ray_laptop | sorry for the delays. I'm home and subject to interruptions | 17:00.34 |
| Robin_Watts | Suppose I have a prn device. When does that device decide whether or not it's a clist device? On the open? | 17:00.36 |
| ray_laptop | Robin_Watts: in the gdev_prn_allocate | 17:00.52 |
| | and children | 17:01.01 |
| Robin_Watts | which happens on gdev_prn_open, which happens on the device_open. | 17:02.02 |
| | So changing the page size for a device would close and reopen the device. | 17:02.13 |
| | But assuming that we have a file that prints lots of pages, all the same size, the clist structure is preserved across all of them. | 17:02.46 |
| ray_laptop | Robin_Watts: the clist device is set up in gdev_prn_setup_as_command_list | 17:03.33 |
| | Robin_Watts: the gdev_prn_maybe_reallocate_memory is used in gdev_prn_put_params to decide if it needs to juggle things based on space_params, width, height, and page_uses_transparency | 17:07.11 |
| Robin_Watts | put_params can happen on an open device? | 17:09.03 |
| ray_laptop | Robin_Watts: yes, open, or closed | 17:09.33 |
| | Generally it is only on a closed device for all of the initial put_params calls. Then the device generally stays open | 17:10.29 |
| | That is critical for something like the pdfwrite device that want to stay open across pages and collect stuff for an entire output file until they finally get closed | 17:11.53 |
| Robin_Watts | ray_laptop: Ah, true. | 17:13.17 |
| | so page size changes can't close a device. | 17:13.25 |
| ray_laptop | That's why devices changing depth (bit* devices) need to be careful because the gdev_prn_maybe_reallocate_memory doesn't handle everything | 17:13.27 |
| | Robin_Watts: gs_putdeviceparams allows a device to close, however. This fn returns 1 if the device closed and needs to be reopened | 17:17.42 |
| | Robin_Watts: this is discussed somewhat in doc/drivers.htm#Life_cycle | 17:20.49 |
| | Robin_Watts: BTW, the process_page stuff should be documented in doc/drivers.htm -- probably the planar buffer mode should be discussed here as well | 17:24.29 |
| | the bane of all progress is documentation ;-) | 17:24.45 |
| | Robin_Watts: on another topic, I _did_ manage to get a crude profile with CodeTune (sampling only, no instrumentation mode) and on J6 the impact (NRT=0) of gsicc_get_link_profile is .5% | 17:29.47 |
| | Robin_Watts: pms_blueNoiseMask_avg is 0.88% | 17:30.43 |
| Robin_Watts | ray_laptop: If the SSE routines are so tiny, where the hell is the time going? :) | 17:31.07 |
| | bg_print: Is that always a single thread doing the printing ? | 17:31.38 |
| ray_laptop | Robin_Watts: sorry. pms_blueNoiseMask_avg is 8.9% (typo) | 17:32.13 |
| Robin_Watts | oh, no, we have a single bgprint thread that might fork multiple rendering threads? | 17:32.30 |
| ray_laptop | Robin_Watts: with BGPrint, if NRT=0, then it is a thread, but a background thread will fire of NRT threads to render | 17:33.19 |
| | Robin_Watts: right. That's why I timed BGPrint with NRT=0 and NRT=3 | 17:33.49 |
| | Robin_Watts: I'm going to re-run the profles, but the results look plausible. For example gx_dc_devn_fill_rectangle (and children) account for 43% of the time (most of that is mem_planar_fill_rectangle_hl_color) | 17:43.58 |
| Robin_Watts | ray_laptop: Which was was J6? The 20 or 100 page one? | 17:45.29 |
| kens | Goodnight all | 17:47.32 |
| Robin_Watts | Right, J6 is the 100 page one. | 17:49.17 |
| ray_laptop | Robin_Watts: I've run the profile with CodeTune several times, and of the gsicc functions, gsicc_get_link_profile is negligible < 0.3 % -- I do see gsicc_set_device_profile as 5.4% and gsicc_profile_new as 4.2%, but I don't think the persistent cache is going to help much. | 18:41.16 |
| | but mem_planar_fill_rectangle_hl_color is 51% of the time | 18:42.35 |
| | and gx_image_fill_masked is 30% | 18:43.39 |
| mvrhel_laptop | Robin_Watts: I know you are in the middle of icc cache stuff, but did you get a chance to review my mupdf commit? | 18:43.54 |
| ray_laptop | mvrhel_laptop: for the DirectX printing ? | 18:44.17 |
| Robin_Watts | mvrhel_laptop: Yes. | 18:45.17 |
| | It's fine. | 18:45.19 |
| | At least, its looks plausible. I don't claim to understand it. | 18:45.42 |
| | ray_laptop: Can you try profiling J12 please? | 18:46.05 |
| ray_laptop | Robin_Watts: ok. | 18:46.35 |
| Robin_Watts | It was J12 where I saw (or thought I saw) the huge time spent in lcms. | 18:47.06 |
| mvrhel_laptop | Robin_Watts: ok thanks | 18:47.15 |
| ray_laptop | Robin_Watts: First trying NRT=0 (profiling is less misleading with that) | 18:49.24 |
| Robin_Watts | Hmm. I've backed out all my changes, and this thing is still crashing :( | 18:54.36 |
| | gswin32c.exe -sDEVICE=psdcmyk -dNumRenderingThreads=3 -o out -r300 -dLastPage=10 -dMaxBitmap=10000 ../Mytests/pdf_reference17.pdf | 18:54.57 |
| | great. It's an existing bug :( | 19:00.29 |
| ray_laptop | Robin_Watts: OK, so on J12 (20 pages) I see 23% (NRT=0) trying NRT=4 next | 19:02.02 |
| Robin_Watts | ray_laptop: 23% in lcms or 23% in get_link? | 19:03.01 |
| ray_laptop | Note that image_render_color_DeviceN is 39% | 19:03.08 |
| Robin_Watts | ray_laptop: That would be the function that calls lcms? So the 39% includes the 23% of lcms ? | 19:03.46 |
| ray_laptop | Robin_Watts: and gscms_get_link is 20% which indicates cache misses or at least very expensive process. | 19:04.47 |
| | I'm going to bp that in a debug build to see how many times it is being called (w/o instrumentation, sampling doesn't tell me) | 19:05.27 |
| Robin_Watts | OK, so my changes were fine. | 19:08.10 |
| | just wasted an hour hunting for a bug that's there anyway. :( | 19:08.33 |
| ray_laptop | Robin_Watts: which bug # ? | 19:11.35 |
| | Robin_Watts: I'm going to re-run that profile, but I only see 19 calls to gscms_get_link -- and that's 20% ??? | 19:13.55 |
| | those must be *very* expensive profiles to compute | 19:14.36 |
| | The next thing down on the profile was cmsCreateMultiprofileTransformTHR | 19:16.03 |
| marcosw | henrys: who do you suggest I assign the ghostscript windows print queue issue that came in late last week to? | 19:16.49 |
| aksr | hi guys, i'm writing a bash function with an *optional* argument (-dLastPage), is there a way to set it be the _last_ page, no matter which page number it is? | 19:19.12 |
| Robin_Watts | -dLastPage=999999999 ? | 19:23.07 |
| | Just guessing, but that might work. | 19:23.23 |
| ray_laptop | it spends a lot of the time in OptimizeByResampling | 19:27.47 |
| | aksr: If you don't put in -dLastPage, it is automatically set to the last page | 19:28.16 |
| mvrhel_laptop | sigh so microsoft is pretty much forcing one to go to Visual studio 2013 if you want to do windows 8 .1. I cant do any remote debug on the surface with 2012. Robin, I am moving the winRT project to 2013 | 19:29.01 |
| Robin_Watts | mvrhel_laptop: Sure. That makes sense. | 19:29.21 |
| mvrhel_laptop | now let me see if I can get things set up for a tab and spaces initialization | 19:30.13 |
| Robin_Watts | ray_laptop: What device were you sampling? | 19:32.18 |
| ray_laptop | the xxxx-aps at -r600 and -dBandHeight=128 | 19:33.12 |
| Robin_Watts | ray_laptop: I have to run to the station to get Helen in a mo. | 19:34.36 |
| | but I've just pushed my commit onto robin/master | 19:34.52 |
| aksr | ray_laptop: yes, but some variable like "last" or something, would have been good for this | 19:40.16 |
| Robin_Watts | "-d" means a number. | 19:40.43 |
| | so you can't -dLastPage=last | 19:40.51 |
| aksr | digit? | 19:41.00 |
| Robin_Watts | We could potentially do -dLastPage=-1 or something. | 19:41.01 |
| aksr | ..or that, i doesn't matter if it signifies *the* last page | 19:42.00 |
| Robin_Watts | ray_laptop: Damn. Still looks like OptimiseByResampling is taking 46% here. | 19:43.17 |
| ray_laptop | aksr: setting it to 1g will suffice (all numbers can have k, m, or g suffix for *1024 *1024*1024 or *1024*1024*1024) | 19:43.29 |
| aksr | i understand. ;) | 19:44.05 |
| Robin_Watts | ray_laptop: I gotta run. bbl. | 19:44.24 |
| ray_laptop | Robin_Watts: talk to you later | 19:44.56 |
| aksr | ray_laptop, Robin_Watts, thank you | 19:45.35 |
| mvrhel_laptop | and of course, retargeting to 8.1 has some issues :( | 20:22.29 |
| | bbiaw | 20:24.56 |
| ray_laptop | mvrhel_laptop: MS wants to keep s/w engineers employed trying to guess what will work for portable s/w :-/ | 20:28.46 |
| | mvrhel: (for the logs) with J12, I'm seeing much of the case of the link profiles that are expensive to generate are cases where the input_profile->hashcode and the output_profile->hashcode are the same. Shouldn't those be recognized and map to an "identity" xform ? | 21:16.50 |
| | However, I thought the output profile for the xxxx-aps device would be CMYKB | 21:20.41 |
| zeniko | Robin_Watts (or FTL): just came to say hi and mention that there are a few minor fixes for review on zeniko/mupdf | 21:54.51 |
| | tor7 (or FTL): The fz_load_system_font bits aren't enough for what we'd need for SumatraPDF. Should I look into what further extensions we'd need or are you still working on that API? | 21:57.46 |
| | IIRC, we try to load system fonts in pdf_load_builtin_font as well as in pdf_load_substitute_cjk_font and even in pdf_load_system_font for when a collection has been specified (and have a list of system fallback fonts we try in pdf_load_substitute_cjk_font first). | 21:59.53 |
| ray_laptop | mvrhel_laptop: Did you see my question. With J12 I see it going through the relatively expensive "OptimizeByResampling" with the in and out profile hashcodes the same. Do we need to do this ? | 22:21.52 |
| mvrhel_laptop | ray_laptop: I did not see your question | 22:22.15 |
| ray_laptop | or is there a "shortcut" to skip this ? | 22:22.17 |
| | i.e. identity xform | 22:22.30 |
| ray_laptop | doesn't understand what else might affect the link | 22:22.57 |
| | this relates to what Robin_Watts is trying to optimize with persistent cache. | 22:24.06 |
| mvrhel_laptop | ray_laptop: we could add in code to avoid the creation of the link when the profiles are the same, since we end up not doing the transform anyway for this case. | 22:25.06 |
| ray_laptop | with the J12 file, in gsicc_get_link_profile, when it fails to find it in the cache, there may be a shortcut. | 22:28.30 |
| mvrhel_laptop | ray_laptop: the link would still be there | 22:28.49 |
| ray_laptop | circa ln 769 | 22:28.53 |
| mvrhel_laptop | it would just have an identity value set | 22:29.03 |
| | and the handle that lcms uses could be bogus | 22:29.14 |
| ray_laptop | mvrhel_laptop: if it isn't found, it's the first time through, then we need to set a cache slot to the identity link, right ? | 22:29.44 |
| mvrhel_laptop | ray_laptop: there is no "identity link" | 22:30.14 |
| | there could be | 22:30.26 |
| | but we would need to rework a few things | 22:30.55 |
| ray_laptop | why does a profile with the same hashcode need to do OptimizeByResampling (that's what we'd like to avoid) | 22:31.12 |
| mvrhel_laptop | at the time I started this, it was pointed out to me that due to rendering intents some people like to go through identity profiles | 22:31.24 |
| | that is cases where the source and destination profiles are the same | 22:31.49 |
| ray_laptop | mvrhel_laptop: oh, so the hashcode doesn't take the rendering intent into account ? | 22:32.08 |
| mvrhel_laptop | I however, effectively avoid doing those transformations, although the transforms are calculated | 22:32.16 |
| | ray_laptop yes it does | 22:32.22 |
| ray_laptop | seems like that would cause false hits in the cache | 22:32.28 |
| mvrhel_laptop | it takes in all the settings | 22:32.37 |
| | if the source and destination profile are the same though, we currently don't transform the colors | 22:33.37 |
| | we do end up computing a link though, which if i understand your question, you would like to avoid | 22:34.02 |
| ray_laptop | mvrhel_laptop: OK, so gsicc_compute_linkhash does check the rendering_params | 22:34.07 |
| mvrhel_laptop | yes. along with black point compensation and other items | 22:34.23 |
| | black preservation | 22:34.32 |
| | etc | 22:34.35 |
| | anyway, let me review the code a bit this week and I will see if I can avoid creating the profile link for the general case | 22:35.32 |
| | when the profiles are the same | 22:35.40 |
| ray_laptop | mvrhel_laptop: or at least the need to resample | 22:36.28 |
| mvrhel_laptop | to avoid that, one needs to not have lcms create the link | 22:36.49 |
| | which is what I will do | 22:36.53 |
| | ray_laptop ^^ | 22:37.02 |
| ray_laptop | mvrhel_laptop: OK. They have lots of optimization checks I see. Thanks for checking this. | 22:37.45 |
| mvrhel_laptop | ok I am very frustrated with all that broke in the UI with the move to 8.1 | 22:53.08 |
| ray_laptop | mvrhel_laptop: sorry to hear that. Reminds me of the old days when working on Windows drivers. Extremely volatile was an understatement. Seems like every windows update jiggled the jello | 23:08.49 |
| mvrhel_laptop | yes. this is a bit much for a change from 8.0 to 8.1. not to mention the need for 2013 over 2012. I hope they don't do this all again in 2014 | 23:09.43 |
| | I have a very irritating flicker when I zoom now and I don't see why that is happening | 23:10.09 |
| ray_laptop | Are there free "Express" versions for VS 2013 that are adequate to the task ? | 23:10.35 |
| | or do you have to pay for upgrades each time ? | 23:10.56 |
| mvrhel_laptop | 2012 to 2013 requires $99 upgrade | 23:11.55 |
| ray_laptop | usually it took about a year of "updates" for a version release of Windoze to become usable | 23:12.00 |
| mvrhel_laptop | for professional which includes the profiler | 23:12.03 |
| | official release for 2013 is wed. | 23:12.29 |
| ray_laptop | my experience with the VS2008 profiler if *NOT* good. BSOD as soon as starting a session :-( | 23:12.48 |
| | so by Nov 2014 is should be workable ;-) | 23:13.15 |
| mvrhel_laptop | exactly | 23:14.33 |
| ray_laptop | suspects that C and C++ sucks hind tit inside MS. As long as it works for .NET apps, everybody else is essentially "we'll fix that someday, maybe" | 23:15.02 |
| mvrhel_laptop | ray_laptop: this is probably true. | 23:34.04 |
| | one more hour of sunlight. days are short now. need to take care of a few things bbiaw | 23:34.31 |
| ray_laptop | It seems that even though there page says "from $299" for 2013 pro, this must be an average. Upgrades from 2012 Pro ar $99 and the only other option is "full" for $499 | 23:42.39 |
| | and there is probably (typically) no support if the profiler sucks as badly as my $$$$ 2008 version does. | 23:43.56 |
| | Oh, well. Unless someone knows a cheaper way to get it, I'll probably go ahead | 23:44.40 |
| | Forward 1 day (to 2013/11/12)>>> | |
IRC Logs