| | <<<Back 1 day (to 2015/02/08) | 20150209 |
| kens | morning sebras | 10:37.00 |
| agile_ | hello anyone here | 11:38.32 |
| kens | No | 11:38.46 |
| agile_ | im having some issues integrating mupdf in my android project | 11:39.27 |
| | fatal error: mupdf/fitz.h: No such file or directory | 11:39.49 |
| | any ideas? | 11:39.53 |
| kens | Not from me, I don;t work on MuPDF. I *think* that m ight be a generated file, which would mean you haven't followed all the steps in 'hot to build for Android' | 11:40.36 |
| | s/hot/how/ | 11:40.42 |
| chrisl | no, fitz.h isn't a generated file - it simply means that your include path isn't set correctly | 11:41.28 |
| agile_ | chrisl: do you know where it lives? | 11:42.52 |
| | #include "mupdf/fitz.h" | 11:43.02 |
| kens | Well, henry was correct about the reference counts of the colour spaces. When the garbage collector runs I see that the colour spaces which are freed (and point to ICC profiles) have a reference count of 1. So the GC is fixing up a reference counting problem. What's much less clear to me is why the reference count of the colour space is incorrect. | 11:43.34 |
| chrisl | agile_: it's in "include/mupdf" in the mupdf repo | 11:44.00 |
| | kens: I'm not sure *Ghostscript* uses the reference counting at all | 11:44.22 |
| kens | chrisl I htink it does, at least sometimes. I sometimes see the ICC profile being freed, and the reference count is 0. And the GC hasn't run at that point. | 11:45.03 |
| | SO it 'looks like' if the reference count drops to 0 we do free the space, otherwise we rely on GC to fix up the problem. | 11:45.35 |
| | And because the ICC profiles aren't added to the GC tracked memory, the GC doesn't run all that often, leading to large memory consumption by the (550Kb) profiles. | 11:46.16 |
| chrisl | kens: I think the graphics library does reference counting, I'm not sure that the Postscript interpreter end of things does - I don't know whether that's relevant.... | 11:46.30 |
| kens | It could be... Its not just the FOrms that are causing the problem, I see the spaces being held over outside the forms too, but because the first file has so *many* forms, the problem gets magnified. | 11:47.15 |
| | gs_setcolorspace does a decrement of the refreence count | 11:50.06 |
| | And if we get to a rc of 0 then we free the space | 11:50.21 |
| | I wonder if the basic setcolorspace isn't doing that. | 11:51.18 |
| agile_ | chrisl: do i need to put those files in library project | 11:52.05 |
| chrisl | agile_: you need to set your include path so the compiler can find the header files | 11:52.33 |
| | I wonder why we need rc_decrement_cs() and rc_decrement_only_cs(), as well as rc_decrement() and rc_decrement_only()??? | 11:59.38 |
| kens | Beats me.... | 11:59.48 |
| agile_ | chrisl: where do i set that or is it I need put the include files in the library project | 11:59.55 |
| Robin_Watts | agile_: If you're using our build files, then the include paths should be set up for you. | 12:00.28 |
| | If you're using some other build system of your own choice, then it's up to you to know how to work it. | 12:00.48 |
| | Yes, the include files need to form part of your project. | 12:01.06 |
| chrisl | I think we should remove rc_decrement_cs()/rc_decrement_only_cs() - they are totally redundant...... | 12:01.52 |
| kens | Really ? let me look | 12:02.03 |
| chrisl | base/gscspace.c | 12:02.21 |
| Robin_Watts | chrisl: Well, they allow for pcs being NULL, which rc_decrement doesn't... | 12:02.53 |
| chrisl | Robin_Watts: yes, it does.... | 12:03.03 |
| kens | Are you sure ? I think it does | 12:03.06 |
| Robin_Watts | actually, it does. | 12:03.12 |
| kens | Nested bloody macros, grumble, grumble | 12:03.31 |
| Robin_Watts | So yes, completely redundant *EXCEPT* if people want to breakpoint colorspace rc changes ? | 12:03.33 |
| chrisl | Hence: "totally redundant"..... | 12:03.33 |
| kens | and rc_decrement_cs is identical to rc_decerement_cs_only ? bizarre | 12:04.19 |
| chrisl | Robin_Watts: using that argument, we should have special increment/decrement methods for *every* reference counted structure | 12:04.28 |
| kens | runs away screaming | 12:04.43 |
| Robin_Watts | chrisl: I'm not saying it's a good argument. | 12:05.01 |
| | I'd be in favour of stripping it out, I think. | 12:05.10 |
| kens | I htnk we can already do a conditional breakpoint based on the type anywa | 12:05.13 |
| Robin_Watts | I just thought I'd mention the only possible reason I could think for keeping it, in case either of you said "ah, yes..." | 12:05.33 |
| chrisl | The comment says: "Abstract the reference counting for color spaces so that we can also increment the ICC profile if there is one associated with the color space" - but we don't do that...... | 12:05.52 |
| kens | TO be honest, its probably worth killing it, but its not the source of the problem. | 12:05.56 |
| Robin_Watts | I bet it's a historical hangover. | 12:06.07 |
| kens | beat me to it | 12:06.13 |
| chrisl | kens: No, I wasn't suggesting it was the issue, but it does add to the general confusion..... | 12:06.35 |
| kens | Oh sure, but I have plenty of that already :-) | 12:06.51 |
| chrisl | kens: it's possible that when we garbage collect objects, we're not twiddling the reference count if they reference a color space - historically, that wouldn't have been necessary | 12:09.53 |
| kens | Hmm : | 12:09.54 |
| | " /* Have one increment from the color space. Having these tied | 12:09.54 |
| | together is not really correct. Need to fix that. ToDo. MJV */" | 12:09.54 |
| | chrisl I'm happy with the garbage collector, the problem as I see it is that the reference count is 1 when it shouldn't be, which is why we hold onto the spaces. The GC correctly determines that there are actually no references ot the spaces, and releases them. | 12:11.06 |
| | I'm 'guessing' at the moment that this is something to do with gsave and grestore, but I'm not 100% on that | 12:11.34 |
| | At least sometimes we do correctly ref count the space on gsave/grestore (even when nested 3 deep) and release the space after the last grestore But sometimes, we don't..... | 12:12.58 |
| | More debugging required :-( | 12:13.11 |
| chrisl | kens: yeh, I'm thinking about something like a shading, which I would expect to hold a reference to the color space.... if the shading gets gc'ed and we don't adjust the reference count for the color space, we'd see a problem | 12:14.25 |
| kens | Hmm, I've caught Robin's problem, that wasn't me that left, freenode kicked me off | 12:16.17 |
| Robin_Watts | kens: Was solved for me by restarting chatzilla. | 12:17.20 |
| kens | I'm using Miranda. But its only happened once so we'll see | 12:17.41 |
| | OK lunch, bbiab | 12:29.29 |
| henrys | tor8:we have a contact now in vietnam that will send a "cease" letter to NVA if we provide strings from the binary that show mupdf use. | 13:31.27 |
| | tor8:can you send me the strings? I looked my self it looks like they've taken djvu as well. | 13:36.33 |
| kens | chrisl I may be mistaken but it looks to me like the 'rogue' colour spaces are allocated as some result of the forms having transparency groups. THe first thing these forms so is a 'setcolorspace', but I'm seeing the ICCBased space being set before we get ot hte start of the stream. I'm assuming this is because the form has a Group, and the group declares transparency. In the particular form I'm looking at, there is nothing els | 13:38.41 |
| | e really that can be causing this, it just creates a path and fills it. | 13:38.41 |
| | It 'looks like' if we start a form with a Group, we set the colour space (possibly the current space) but when we exit the form, we don't count it back down. | 13:39.25 |
| chrisl | kens: that's quite possible - I fixed a number of such reference counting issues in the transparency code a while back, but I had no real confidence I'd found all of them | 13:40.25 |
| kens | Yeah, not assigning blame, just trying to figure out what's going on..... | 13:40.42 |
| | And how ti fix it :-) | 13:40.49 |
| henrys | kens: is it just with high level devices? | 13:43.42 |
| kens | No, its reported against rendering devices. I haven't tried high-level devices | 13:44.01 |
| | THe example command line is ppmraw | 13:44.16 |
| henrys | kens: running without clist and that pattern bitmap clist stuff would eliminate those likely suspects. feel free to hand it off though you probably shouldn't be stuck with it. | 13:47.16 |
| | chrisl: I get a lot more symbols if I use the urw otf fonts vs. the fontforge conversion of the Type 1's to otf. I haven't looked at exactly what's going but we might want to be wary of fontforge conversions. | 13:48.55 |
| chrisl | henrys: we probably need to do more than just the naive, default conversion in fontforge | 13:49.48 |
| henrys | chrisl: also, I'm using a later version on the mac, the linux distributions are way behind with ff. | 13:51.31 |
| chrisl | henrys: I'd be surprised if that made a difference to the conversion, but you never know. I can easily update | 13:53.24 |
| henrys | chrisl: I was wondering if it just limits the output to what can be reached by the standard encoding in the conversion, not sure... | 13:55.38 |
| chrisl | henrys: it's definitely not that...... | 13:56.54 |
| kens | henrys I'm not sure who else to hand this to, other than Micahel who is supposed to be working on SOT. I don't think its clist, or patterns, the spaces I'm seeing all appear to be allocated as the result of a Form with a Group dictioanry. | 13:58.05 |
| chrisl | henrys: for example, the BookmanURW Light OTF/CFF I get converting from our Type 1 font has 364 glyphs in it (including .notdef) | 14:00.33 |
| agile_ | Robin_Watts: i tried putting include folder into project but still no good. MUPDF := ../.. - that is 2 directories up right? | 14:01.57 |
| chrisl | henrys: the extra symbols you see - is that in PCL/PXL? | 14:02.11 |
| henrys | chrisl: I just looked at the pcl bmpcmp and I have more symbols, haven't looked further. | 14:03.42 |
| agile_ | Robin_Watts: which dir is it meant to go in - | 14:04.00 |
| chrisl | henrys: okay, it's just I just thought, going through the CFF code in Ghostscript, we're probably not getting the extended glyph name mapping we get with Type 1 and TTF | 14:04.53 |
| henrys | chrisl: I'l look at it today. Just wanted to make you aware of it so you check the conversion doesn't loose anything. I don't think we have glyph coverage for all fonts in the cluster test. | 14:05.12 |
| chrisl | henrys: I'm suspicious that some of the rendering diffs I saw on Thursday may well be due to not doing the extended glyph name mappings for CFF.... obviously doesn't apply to PCL, though | 14:06.30 |
| | henrys: I'm also guessing that the OTF fonts from URW use accurate Unicode codepoints for all the glyphs, where fontforge may well be using a heuristic to get Unicode code points (it *definitely* does that for Type 1 to TTF conversions). | 14:08.59 |
| agile_ | chrisl: any ideas bud regarding the path to the include folder | 14:09.10 |
| kens | Surely you need the 'include' directory, so ../include or ../../include ? | 14:09.58 |
| chrisl | agile_: you need to add the path to the include folder to your compiler command line, usually the command line parameter is -I | 14:10.14 |
| agile_ | oh right | 14:11.07 |
| | kens: i tried putting both in those but same error | 14:13.26 |
| kens | agile_ : No idea then, sorry. you're working on a system unfamiliar to me | 14:13.48 |
| | Are you using the supplied builds ? | 14:14.09 |
| agile_ | chrisl: mac, android studio | 14:14.13 |
| | kens: yes | 14:14.21 |
| kens | Well, htey are supposed to work, but I don't htink we use Android Studio. I may be wrong. | 14:14.38 |
| chrisl | agile_: means nothing to me - I use neither mac nor android..... nor do I actually work on mupdf | 14:15.10 |
| tor8 | friday was a bizarre day... district heating pipe burst, flooding downtown in a river of steaming hot near-boiling water... | 14:15.47 |
| kens | O.O | 14:16.06 |
| | Sauna :-) | 14:16.09 |
| tor8 | steamy! | 14:16.16 |
| | http://www.dn.se/OAS/lund_1000B.jpg | 14:16.40 |
| chrisl | "district heating"? Crumbs...... | 14:16.45 |
| kens | How very apocalyptic looking.... SHould have run a zombie LARPG | 14:17.03 |
| Robin_Watts | agile_: The idea is that you add 'include' to the include paths. | 14:17.19 |
| | That way, when stuff does: #include "mupdf/blah.h" it will find it. | 14:17.33 |
| agile_ | Robin_Watts: you mean environment variables | 14:18.02 |
| Robin_Watts | agile_: No. | 14:18.09 |
| agile_ | Robin_Watts: oh | 14:18.16 |
| Robin_Watts | I mean compiler include path. | 14:18.17 |
| | when you call the compiler, generally you can do: -Ipath | 14:18.35 |
| | and the compiler will look in that path for include files. | 14:18.49 |
| agile_ | Robin_Watts: i still use an old version of mupdf and it works which references those header files | 14:20.07 |
| Robin_Watts | agile_: Sorry, short of getting a complete dump of your project from you, and trying it locally I don't see how I can help you. | 14:21.09 |
| | And I'm not doing that, cos I don't use Android Studio, so I don't have it installed. | 14:21.22 |
| chrisl | Didn't older versions put the headers in "include" rather than "include/mupdf"? | 14:21.46 |
| Robin_Watts | chrisl: Not for a very long time. | 14:21.57 |
| agile_ | Robin_Watts: ok given the built project, i put the header dir and then what | 14:22.20 |
| Robin_Watts | agile_: Sorry, I don't understand. | 14:22.38 |
| kens | Hmmm, so in gs_setcolorspace_only, we decrement the reference count of the colour space using rc_decrement_only_cs, that falls through to rc_free_struct_only, and does not call the finalise routine for hte ICC profile. | 14:23.05 |
| chrisl | kens: aren't profiles reference counted, too? | 14:23.36 |
| kens | Yes, but the refrence count is only decremented when called from a colour space finalise routine | 14:23.59 |
| | And we didn't call the ifnalise...... | 14:24.05 |
| | Even though the color space reference count is now 0 | 14:24.34 |
| | Which must be some kind of problem, because I see the4 GC has hte colour space with a ref count of 1. SO I must be looking at the wrong problem :-( | 14:24.58 |
| agile_ | Robin_Watts: so before building mupdf, you have to set include path | 14:25.00 |
| Robin_Watts | agile_: Again, I don't understand. | 14:25.22 |
| | How *exactly* are you using mupdf? You say that you're using the supplied builds, but clearly you aren't, cos the supplied builds don't work with android studio. | 14:25.59 |
| | So, I want you to tell me, as explicitly as possible, what you're actually doing. | 14:26.23 |
| agile_ | Robin_Watts: Sure. 2 min | 14:30.14 |
| | Robin_Watts: Downloaded source right using git clone --recursive git://git.ghostscript.com/mupdf.git | 14:34.53 |
| | Robin_Watts: When to platform->android and then ran build.sh | 14:35.12 |
| | Robin_Watts: I also set the all option to build it for all processors in Application.mk | 14:35.45 |
| Robin_Watts | OK, hold on. | 14:35.58 |
| | I would have expected the build.sh stuff to fail due to generated not being present. | 14:36.12 |
| agile_ | Robin_Watts: sorry I done make before doing build.sh | 14:37.15 |
| Robin_Watts | Ah, ok. | 14:37.23 |
| | Keep going then. | 14:37.29 |
| agile_ | Robin_Watts: and then i just imported that project into android studio | 14:38.30 |
| Robin_Watts | Ok, that's where I am confused. | 14:39.02 |
| agile_ | Robin_Watts: as a library of course | 14:39.19 |
| tor8 | henrys: I sent you an email of a few string|grep outputs on the NVA Reader exe | 14:39.22 |
| Robin_Watts | If you're trying to import the java, and use the build C library unchanged, then that should work fine. | 14:39.56 |
| henrys | tor8: thanks! | 14:39.59 |
| Robin_Watts | And the whole 'include path' thing doesn't come up. | 14:40.08 |
| agile_ | Robin_Watts: yes exactly | 14:40.17 |
| Robin_Watts | But if it's failing to find the include paths for you, then you must be including the .c files too, which is not what you want to do. | 14:40.35 |
| | Am I right in thinking you don't want to do any c programming - you're just wanting to program at the java level ? | 14:41.07 |
| henrys | tor8: perhaps they've just taken sumatra, is that where the djvu is coming from? | 14:41.25 |
| tor8 | henrys: yeah. their product looks like a minor reskin of sumatra. | 14:42.04 |
| agile_ | Robin_Watts: correct | 14:42.07 |
| Robin_Watts | OK, so the problem is that you've imported too much into android studio. | 14:42.23 |
| | You want to import the built lib, but not the .c and .h files. | 14:42.37 |
| | I can't tell you any more details than that because I've never used android studio myself. | 14:42.52 |
| agile_ | Robin_Watts: ok cool. that is what I done initially then it start complaining about fitz.h | 14:43.47 |
| | Robin_Watts: what about eclipse? | 14:44.11 |
| Robin_Watts | agile_: No, if it's complaining about fitz.h then you have imported .c or .h files. | 14:44.32 |
| | If you've imported just the built lib, then nothing in your code will touch fitz.h | 14:44.57 |
| agile_ | Robin_Watts: i think when I did import using android studio it didn;t do it properly | 14:44.58 |
| Robin_Watts | I don't use eclipse either. | 14:45.04 |
| agile_ | Robin_Watts: ok no problem. ill try building again | 14:47.57 |
| henrys | tor8: and it looks like they have the URW fonts embedded so I'll report that too. | 14:49.09 |
| | tor8: thanks hopefully we can stop these knuckleheads. | 14:57.13 |
| | They aren't even worthy pirates. All this debug stuff in the exe, amateurs. | 15:00.03 |
| tor8 | rank amateurs...haven't even stripped the exe | 15:00.20 |
| | makes it easier to clobber them, though | 15:00.34 |
| henrys | bbiab | 15:01.22 |
| Robin_Watts | tor8: robin/master has a working version of the mupdf display list rewrite on. | 15:19.49 |
| | I want to replace some of the magic numbers by enums, but it's close. | 15:20.21 |
| tor8 | Robin_Watts: has it changed much since last I looked a week or two ago? | 15:31.42 |
| Robin_Watts | tor8: Previously it had the writing side, but not the reading side. | 15:32.06 |
| | Now it has the reading side too. | 15:32.11 |
| | The writing side has changed a bit, but nothing major. | 15:32.36 |
| tor8 | ah. | 15:33.15 |
| | it looks familiar, I remember griping about the number of arguments to fz_append_display_node :) | 15:33.35 |
| | looks good; but it'll merge conflict with the drop branch | 15:34.04 |
| | which is in fairly good shape now if you want to take a look and give opinions | 15:34.31 |
| Robin_Watts | will look while compiles run :) | 15:41.58 |
| henrys | tor8: he also wants some error or menu messages. Did you see anything familiar? If so email them to me. | 15:58.31 |
| | when I talk to the lawyer we are on equal footing: neither of have any idea what the other is saying ;-) | 16:08.58 |
| tor8 | henrys: check your email for some screenshots | 16:09.00 |
| | side by side comparison with sumatrapdf | 16:09.20 |
| henrys | tor8: these guys are really something else, it is possible they don't know what they are doing is wrong... I can't believe they'd be so daft if they knew they were stealing. | 16:10.45 |
| tor8 | henrys: will that be enough, or do you want me to dig out message strings? | 16:11.06 |
| henrys | tor8: I'll send this and copious explanation about the debug strings and I think we should be good but keep the exe around, he may want more. | 16:12.18 |
| tor8 | henrys: I'll email you the exe (renamed to .dat) so you can run strings on it yourself should the need arise | 16:13.01 |
| henrys | tor8: I have it I'm good. | 16:13.28 |
| tor8 | oh, okay. | 16:13.34 |
| | well, then I've got it saved in my email as well :) | 16:13.43 |
| henrys | I wanted you to look because you are going to more quickly identify mupdf messages. | 16:13.54 |
| tor8 | it's got all of our error messages in there | 16:16.40 |
| | henrys: ignorance is a plausible explanation... lots of folks think open source == public domain | 16:17.47 |
| henrys | kens: hcl? ugh | 16:25.31 |
| | I thought we fired them ;-) | 16:25.50 |
| kens | Yeah, I answered the question, as did ray, but I've no idea if they represent 'someoneelse' in this case | 16:26.00 |
| agile_ | Robin_Watts: hello bud | 16:27.06 |
| Robin_Watts | agile_: hi | 16:27.15 |
| kens | thinks a 1 million page PDF file is insane..... | 16:27.40 |
| agile_ | Robin_Watts: i managed to get it all built and compiled. it works fine on certain android lollipop devices but crashed on others | 16:28.04 |
| | Robin_Watts: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "rand" referenced by "libmupdf.so"... | 16:28.11 |
| | Robin_Watts: any ideas | 16:29.44 |
| tor8 | agile_: you built 32-bit binaries with the 64-bit *target* NDK? | 16:30.06 |
| Robin_Watts | agile_: Yeah. What tor8 said. | 16:30.16 |
| agile_ | yes | 16:30.34 |
| tor8 | the 64-bit *target* NDK by google is broken. it builds non-functional binaries if you use it to compile 32-bit binaries. | 16:30.34 |
| chrisl | Haven't they fixed that yet?? | 16:30.43 |
| Robin_Watts | The 64bit target ndk toolchain is *supposed* to be able to build for both 32 and 64bit targets, but it's broken for 32bit targets. | 16:30.47 |
| tor8 | chrisl: I doubt they even know it's a problem... google, remember? | 16:30.56 |
| Robin_Watts | Hence you should be using the 32bit targetted ndk. | 16:30.57 |
| chrisl | <sigh>...... | 16:31.17 |
| tor8 | chrisl: they went around and closed *all* outstanding bugs for android versions older than the latest as wontfix a few months back | 16:32.01 |
| agile_ | ill give that a shot | 16:32.04 |
| chrisl | Gotta love google..... :-( | 16:33.07 |
| kens | chrisl, latest progress, the extra reference count is caused by an execution of 'gstate', this seems to be due to executing a function called /qstate (meaningful name, not....) which seems to squirrel away the graphics state in a dictionary or some other variable. Looks like we lose track of it after that, and it doesn't get counted down for some reason. | 16:37.58 |
| chrisl | kens: that's, umm, odd..... again, possibly not being counted down by gc. Does the gstate have a "finalize" method? | 16:39.34 |
| kens | Well it seems to work 'normally' but not in this case. I'm having enough trouble figuring out what's callign qstate at the moment.... | 16:40.10 |
| chrisl | kens: well, normally, we'd only get rid of a gstate in a grestore, which does all that stuff explicitly, IIRC | 16:40.52 |
| kens | Indeed, and I suspect this is the root of the problem, its more or less the situation I was describing the other night, except that instead of just saving away a copy of a colour space we're saving a whole gstate. | 16:41.34 |
| | I may know a little more when I find out where the qstate is being called from, I can track teh lifetime of teh gstate then. | 16:42.05 |
| chrisl | So the solution may be to add a finalize method for gstates, or maybe fix one that's already there..... | 16:42.35 |
| kens | Yes, it could be that. I feel I'm slowly working towards an understanding of the problem, not there yet though :-( | 16:43.10 |
| | Hmm, seems to be a result of executing /.pdfruncontext. Looks like we use that to run Forms. Aha! Its called from .execgroup, where there's a commetn which says 'Paint a Form+Group Xobject...' | 16:49.31 |
| | It looks to me like we simply lose track of the reference count once it ceases to be stored on the graphics state stack. | 16:50.36 |
| chrisl | I find it rather worrying that we explicitly store a graphics state like that...... | 16:51.38 |
| kens | Although we count it up when we do a gstate, there seems to be no provision for counting it back down again. | 16:52.01 |
| | I'm inclined to agree, but we do explicitly store the gstate quite frequently | 16:52.22 |
| chrisl | Neither the graphics state nor the imager state have a finalize, so I think there is no way for the garbage collector to know it needs to decrement a reference count | 16:55.17 |
| kens | It looks like when we do a 'gstate' we increment the reference count to make sure that the graphics state doesn't get freed by gsave/grestore/setcolorspace decrementing its reference count. After that, we rely on garbage collection to do the heavy lifting | 16:55.23 |
| | Hmm, so maybe adding a finalise to the gstate would work. | 16:56.03 |
| | I'll look at that tomorrow I guess. | 16:56.11 |
| chrisl | kens: as it's gc stuff, if you'd prefer me to look at it, I can do | 16:56.35 |
| | As you've done the hard work....... | 16:57.01 |
| kens | I'll take a quicj swing at tit tomorrow as I already have teh debugging stuff aet up, if I run into trouble I'll chuck it to you | 16:57.05 |
| | I'm obviously tired, my typing is going haywire again | 16:57.26 |
| henrys | bad luck that the US Artifex folks just switched to this insurance right before the breach http://www.nbcnews.com/business/consumer/anthem-breach-what-should-i-do-right-now-n300796 | 16:57.43 |
| kens | Really ? Ooops..... | 16:57.58 |
| henrys | we've been instructed to wait for post mail (not email) from them for instructions. I have no idea what they are going to tell me. Counsel me how to get through identity theft ? | 17:01.16 |
| Robin_Watts | henrys: Get you to sign away your right to join the inevitable class action against them. | 17:03.06 |
| | henrys: The snail mail packet will contain your new identity. | 17:04.25 |
| henrys | Robin_Watts: yeah that's a possibility | 17:04.26 |
| | Robin_Watts: and a mission? | 17:04.53 |
| Robin_Watts | It'll self destruct in 5 seconds. | 17:05.05 |
| henrys | I may never get it, our mail here is a joke, the neighbors get together and sort out the misfires in my local area but God knows what else gets lost further away. | 17:08.10 |
| agile_ | hey guys | 17:32.29 |
| | got it all working now. appreciate all your help | 17:32.45 |
| | Robin_Watts: slight issue though. Basically, when i save the annotations it hangs for a bit | 17:33.42 |
| | Robin_Watts: but it is blazing quick, around a second on the nexus 9 | 17:34.45 |
| | Robin_Watts: ok ill catch you tomorrow. thanks anyway | 17:38.38 |
| rayjj | mvrhel_laptop: I'm having to dig into the transparency blending math, aka, Hell. Cust 532's off-by-a-little-bit color problem with pattern-clist (vs. bitmap patterns) is due to different blending steps | 18:43.58 |
| mvrhel_laptop | blending modes or steps? | 18:44.24 |
| | rayjj^^ | 18:44.28 |
| rayjj | mvrhel_laptop: there was a bug fix (bug 693498) that "fixed" the colors, but it doesn't look like it does quite the right thing when patterns are being played back from a pattern-clist (it doesn't do the group composite step, but takes a different path) | 18:45.52 |
| | mvrhel_laptop: the mode (Multiply) is being detected/handled | 18:46.47 |
| mvrhel_laptop | 2 years ago. I vaguely remember this | 18:48.00 |
| rayjj | mvrhel_laptop: I'm digging through it. I see where the different numbers are being computed, but the "why" is wrapped up in the "in clist pattern case, rendering occurs directly into primary buffer" which is why it doesn't end up doing the group composite | 18:51.26 |
| | mvrhel_laptop: but if I have an idea of how to fix it, I will definitely want you to review my math + logic for it. | 18:52.19 |
| mvrhel_laptop | rayjj: ok | 18:52.31 |
| rayjj | mvrhel_laptop: otherwise, be glad you're on SOT + gsview | 18:52.47 |
| mvrhel_laptop | rayjj: right now I am getting ready to test this fix for the deviceN named color stuff | 18:53.11 |
| rayjj | have to run an errand, then dive back into debugging | 18:53.26 |
| mvrhel_laptop | Robin_Watts: A couple very minor commits to gsview on my repos if you can take a look when you have the time | 20:13.43 |
| | lunch time now | 20:13.53 |
| | bbiab | 20:15.47 |
| | Forward 1 day (to 2015/02/10)>>> | |
IRC Logs
