| | <<<Back 1 day (to 2018/10/17) | 20181018 |
| sebras | Robin: so I notice that libluratech.vcproj sets IgnoreAllDefaultLibraries to "Yes" while libfreeglut.vcproj doe snot. | 09:26.21 |
| | does not. | 09:26.25 |
| | in the VCLibrariantool. is that intentional? | 09:26.41 |
| Robin_Watts | sebras: but the previous version of libluratech did, and I tried to minimise difs. | 09:26.57 |
| sebras | Robin_Watts: ok. | 09:27.17 |
| | Robin_Watts: I assume that the difference of setting EnablefunctionLevelLinking in ReleaseCommercial but not in Release does not matter as the lib isn't included in Release, right? | 09:32.01 |
| Robin_Watts | The Release lib has no functions in it. | 09:32.44 |
| sebras | oh, because each file is later excluded from the build, I see. | 09:33.36 |
| | Robin_Watts: we do not set WholeProgramOptimization for ReleaseCommerical, should we? | 09:35.00 |
| | I'm not sure what constitutes a program here, perhaps that's only an .exe? | 09:35.45 |
| | do CharacterSet differences matter between DebugCommercial and ReleaseCommercial? | 09:36.27 |
| Robin_Watts | sebras: I don't believe any of that matters. | 09:44.57 |
| sebras | Robin_Watts: DebugCommercial still has DebugInformationFormat set to 4, yet this was changed for the release build. | 09:45.01 |
| Robin_Watts | certainly a batch build I did yesterday worked. | 09:45.11 |
| sebras | Robin_Watts: these are just inconsistencies that I saw. I have no idea if they are relevant/problematic. | 09:46.15 |
| | the precompiledheader settings and setting outputfile to someting .lib seems reasonable though. | 09:46.31 |
| | as well as the chances in the .sln file | 09:46.42 |
| Robin_Watts | I think that possibly the only thing that matters is the change of Configuration type from 1 to 4. | 09:47.19 |
| | But this stuff is so bloody undocumented :( | 09:47.26 |
| sebras | Robin_Watts: doesn't these xml-thingies relate to settings in the GUI in vs200x? | 09:48.14 |
| Robin_Watts | sebras: Mostly, yes. | 09:48.26 |
| sebras | checkboxes and textfields and stuff. | 09:48.27 |
| Robin_Watts | but stuff like "ConfigurationType" doesn't. | 09:48.36 |
| sebras | IntermediateDirectory differs between ReleaesCommerical|Win32 and ReleaseCommercial|x86 should it? | 09:49.01 |
| | oh. | 09:49.09 |
| Robin_Watts | Yes. | 09:49.23 |
| sebras | we include $(PlatformName) for x86 but not for Win32. | 09:49.28 |
| | perhaps that's benign, but I have no idea. | 09:49.38 |
| Robin_Watts | For x64, but not Win32. | 09:49.39 |
| | We put 32bit exes in platform/windows/Release/ | 09:49.53 |
| | and 64bit exes in platform/windows/x64/Release/ | 09:50.05 |
| | (s/exes/exes and objs/) | 09:50.16 |
| sebras | right, well. with that LGTM. | 09:52.36 |
| | Robin_Watts: I wish we had more consistency between the different configurations and also between all the .vcproj files so it is easier for the untrained eye to spot differences. | 09:53.36 |
| | now it seems a little like: this happened to work once, we don't know why, so don't touch it. :-/ | 09:54.05 |
| | I understand why, I just dislike that we have stuff we don't understand. :) | 09:54.24 |
| | Robin_Watts: I'm confused by "Fix line spacing bug in rewriting PDF files." | 09:57.25 |
| | pdf_filter_Tz() divides scale by 100, as does pdf_run_Tz(), yet pdf_out_Tz() multiplies by 100 | 09:59.37 |
| | oh I see now, pdf_run_Tz() and pdf_filter_Tz() are used while parsing and pdf_out_Tz() needs to do the reverse because it is generating a content stream. | 10:02.11 |
| | Robin: well, that LGTM as well in that case. | 10:02.28 |
| Robin_Watts | sebras: Ta. That one is in already. | 10:14.03 |
| sebras | Robin_Watts: right, I hadn't updated master yet. | 10:14.27 |
| Robin_Watts | tor8: had you nodded at this one? http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=8733a6a81931a7bfdac3afdec797c58a0601e473;hp=b867669500593dd3718c8d96507baaff8b32a60d | 13:49.19 |
| tor8 | Robin_Watts: not yet. I see you're writing each band in multiple columns now? | 13:50.47 |
| | so basically tiles | 13:50.52 |
| Robin_Watts | tor8: Yeah. PCL is limited in the line sizes it can send. ****ing stupid PDL. | 13:51.25 |
| | Henry has confirmed that the gpcl delta decompression is broken, and he's fixing that now. (The spec is contradictory) | 13:52.05 |
| tor8 | Robin_Watts: the general shape of things LGTM. I take it you've tested the code to make sure it works? | 13:52.33 |
| Robin_Watts | tor8: A test print on Henrys machine looked plausible. | 13:52.46 |
| tor8 | cool! | 13:52.54 |
| | go for it | 13:52.56 |
| Robin_Watts | Certainly it's a lot closer than it used to be. | 13:53.00 |
| | Ta. | 13:53.02 |
| tor8 | Robin_Watts: I've done some bigger reworkings of the non-LCMS color conversion stuff | 13:53.32 |
| | to make it work with pixmaps that have alpha channels | 13:53.43 |
| Robin_Watts | cool. | 13:53.51 |
| sebras | tor8: nice! | 13:54.03 |
| tor8 | I'm relying on branch prediction to keep them fast. the commits are on tor/master when you got a minute or two | 13:54.17 |
| | the fast CMYK, and generic (especially L*a*b*) needed fixing | 13:54.44 |
| | the gray/rgb conversions work fine in premultiplied alpha space | 13:54.55 |
| | but the non-linear transformations for to/from cmyk and lab need dividing out the alpha first | 13:55.21 |
| | we don't have a non-ICC target build for the cluster | 13:55.45 |
| | I think it would be useful to have | 13:55.52 |
| | maybe we should call the #define FZ_ENABLE_LCMS rather than FZ_ENABLE_ICC? | 13:56.45 |
| | or FZ_ENABLE_CMM | 13:56.56 |
| Robin_Watts | looking | 13:57.38 |
| | Currently it's NO_ICC, right? | 13:58.39 |
| tor8 | yeah, it's NO_ICC currently | 13:58.47 |
| Robin_Watts | I'd be receptive to any more general scheme that let us pick between no icc, lcms, or other builds and wasn't too horrendously complex. | 14:00.02 |
| tor8 | I did consider making the non-lcms build still use the 'cmm' engine thingy | 14:00.35 |
| | but this stuff is quite a tangled mess | 14:00.47 |
| Robin_Watts | As it is at the moment NO_ICC chooses whether we look for profiles etc or not. | 14:00.59 |
| tor8 | hard to see at a glance what is called when and where | 14:01.00 |
| | and there seem to be an awful lot of gotchas, where we don't handle certain combinations of features | 14:01.16 |
| | like spot rendering without icc | 14:01.20 |
| | which just falls flat | 14:01.30 |
| | because the std_conv_pixmap doesn't handle spot channels | 14:01.42 |
| | NO_ICC also controls whether we use any functions in lcms2 | 14:02.25 |
| Robin_Watts | It controls whether color-lcms.c builds anything, yes. | 14:03.13 |
| tor8 | if you want I could spend a week or two cleaning this up and seeing if I can make a general scheme that lets us pick all the options at run-time and hopefully stays simple | 14:03.16 |
| | so we could have both ICC support with color profiles, and fast non-colormanaged device colorspaces | 14:03.41 |
| | if that's even remotely possible | 14:03.47 |
| Robin_Watts | cleaning up is always good. | 14:03.51 |
| | I suspect we'd probably want to have NO_ICC or the equivalent remaining. | 14:04.11 |
| tor8 | I'm expecting to have a compile time option to skip LCMS2 and just use the non-managed colorspace conversions | 14:04.42 |
| Robin_Watts | That would differ from NO_ICC how ? | 14:04.59 |
| tor8 | for when you want a slim and/or faster build and don't care about colors (or want to avoid using our forked lcms2) | 14:05.01 |
| | I don't know if that will be any different from our current NO_ICC behaviour | 14:05.30 |
| Robin_Watts | Or (to be less yoda): how would that differ from NO_ICC? | 14:05.37 |
| | right. | 14:05.46 |
| tor8 | if it's worth having a separate 'don't embed default ICC profiles for Device* colorspaces' | 14:05.47 |
| Robin_Watts | tor8: That sounds to me like you're suggesting an additional halfway house thing. | 14:06.05 |
| | and I'm not sure that's possible. | 14:06.10 |
| tor8 | I'm not sure either | 14:06.15 |
| Robin_Watts | Cos if you start to use ICC profiles for *anything* then they have to be related somehow to the device profiles you're using. | 14:06.36 |
| tor8 | maybe it should just be two separate engines -- one LCMS2 based, and one 'old non-managed crap fast conversions' based | 14:06.51 |
| | and we only build the LCMS2 one if we have the compile time option turned on | 14:07.11 |
| Robin_Watts | tor8: Which, again, is what NO_ICC is. | 14:07.12 |
| tor8 | but can switch between them at runtime | 14:07.18 |
| Robin_Watts | If there are holes in the support offered by NO_ICC for things like spot colors, then those should definitely be fixed. | 14:07.34 |
| tor8 | yeah, but it's not done as separate engines. it's a code base that switches between using an engine, and not using it? | 14:07.43 |
| Robin_Watts | Yes. | 14:07.54 |
| tor8 | yeah, NO_ICC seems untested and looks like it would be broken for spots | 14:07.57 |
| | anyway, I think I would like to have a go at polishing this up a bit | 14:08.20 |
| | and see if I can find the broken corner cases | 14:08.26 |
| Robin_Watts | Doing NO_ICC as a separate engine sounds nice, as long as we can avoid the overhead of actually loading ICC profiles etc. | 14:08.32 |
| | Fixing broken stuff sounds good to me. | 14:08.49 |
| tor8 | yeah, the NO_ICC engine would just noop actual ICC profiles and just look at the 'N' and drop to a matching device colorspace | 14:08.59 |
| Robin_Watts | If you can identify something that's worth having in the cluster, I can look at that. | 14:09.03 |
| tor8 | if we can make it an easy runtime flag, maybe that's easier to add (just another filter option thing like resolutions) | 14:09.39 |
| Robin_Watts | I'm going to have a quick look at the claims of crashing made at the end of bug 699967 | 14:10.16 |
| tor8 | bug 699971 looks like something you might spot quicker. it's a difference between using and not using the display list, and transparency groups. | 14:13.24 |
| Robin_Watts | Sure. | 14:16.20 |
| | tor8: Couple of simple fixes: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=d80be068ec5c50a27199b949cbec03fc27adcc90 | 15:31.28 |
| | 802c802 | 16:33.35 |
| | < <mask bbox="162 377 181 411" s="luminosity"> | 16:33.37 |
| | --- | 16:33.38 |
| | > <mask bbox="162 377 181 411" s="alpha"> | 16:33.40 |
| | We're storing the type of box wrong in the list. | 16:33.45 |
| | tor8: OK, so fix for that is: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=69ff417b417ed66b048f953d9e2b980ba8719385 | 16:39.47 |
| tor8 | Robin_Watts: both fixes LGTM | 21:42.53 |
| Robin_Watts | tor8: Ta. | 23:05.38 |
| | Forward 1 day (to 2018/10/19)>>> | |
Log of #mupdf at irc.freenode.net.