| | <<<Back 1 day (to 2016/01/05) | 20160106 |
| grossberndts | good morning! (depending on your timezone) ;) | 09:21.36 |
| lawrence615 | hello guys, abit of help here.....I managed to build my own source of mupdf following these steps http://mupdf.com/docs/how-to-build-mupdf-for-android. After running ndk-build this is what I get as the final output "[armeabi-v7a] Install : libmupdf.so => libs/armeabi-v7a/libmupdf.so"......But when I import the files in platform/android as a module, it is not recognized as a module | 09:26.30 |
| | where could I be going wrong? | 09:26.42 |
| chrisl | lawrence615: you may have to wait a while for the relevant person/people to possibly answer..... | 09:27.34 |
| | grossberndts: it's certainly morning here - not sure it's terribly good! | 09:27.58 |
| lawrence615 | Also to minify the size I added LOCAL_CFLAGS += -DNOCJK in the Core.mk | 09:28.24 |
| | Okay, Thanks @chris1 | 09:28.39 |
| Robin_Watts | lawrence615: I suspect "a module" requires some special packaging that we don't do. | 10:03.58 |
| grossberndts | chrisl: Reported bug in Debian ghostscript package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810080 | 10:46.56 |
| | Once again thanks for the help. | 10:48.22 |
| simon91 | tor8: morning | 11:16.00 |
| | tor8: I have some issues with our decimal to float conversions. | 11:16.40 |
| tor8 | simon91: morning. are you going to rewrite our strtod as well? :) | 11:17.09 |
| simon91 | thats function lex_number in pdf-lex.c | 11:17.14 |
| | it truncates everything after 10^-9 | 11:17.40 |
| | so 0.000000123456 | 11:17.49 |
| | gets converted into 0.000000123 | 11:18.08 |
| | overflow seems even more weird | 11:19.04 |
| | 10000000000000 (1e13) gets converted to 1.316134912e+09 | 11:19.46 |
| tor8 | simon91: you want Robin_Watts for that discussion, he made the choices when writing that code | 11:19.52 |
| | simon91: but in general, you should never see numbers like that in well constructed PDF files | 11:20.21 |
| | I think we can improve the overflow situation by using floats rather than ints for the intermediate parts of the number | 11:21.30 |
| | but robin may have some nasty words to say about ARM performance if we do that | 11:21.44 |
| Robin_Watts | simon91: Unless we have a specific use case where that goes wrong, I'd not be fussed. | 11:22.37 |
| tor8 | simon91: have you got a sample file that has trouble here? | 11:22.46 |
| simon91 | tor8: yeah the spec says that everything between 10^38 and 10^-38 is valid | 11:23.47 |
| | I don't have a real-world file, so I admit it's nit-picking | 11:25.07 |
| Robin_Watts | That sounds like 'float' range to me. | 11:25.54 |
| simon91 | if I run that first number through gs all digits survive | 11:26.06 |
| | Robin_Watts: yeah its actually FLT_MAX and FLT_MIN | 11:27.03 |
| Robin_Watts | /* We deliberately ignore overflow here. We tried | 11:27.42 |
| | * code that returned INT_MIN/MAX as appropriate, | 11:27.43 |
| | * but this causes loss of data (see Bug695950.pdf | 11:27.45 |
| | * for an example). Tests show that Acrobat handles | 11:27.46 |
| | * overflows in exactly the same way we do (i.e. | 11:27.48 |
| | * 123450000000000000000678 is read as 678). */ | 11:27.49 |
| | simon91: What we COULD do to cope better with small numbers would be to alter the code after 'underflow:' in lex_number. | 11:28.45 |
| tor8 | I think one of the troubles we have is that we're parsing both integers and reals using the same code | 11:28.50 |
| Robin_Watts | We could convert to float at that point, and then handle subsequent digits using floats. | 11:29.10 |
| tor8 | we could get around that by using doubles to parse both (since a double can hold the entire int range) and return a REAL token if the int overflows | 11:29.29 |
| | but that would not match adobe's behaviour | 11:29.34 |
| Robin_Watts | Most numbers wouldn't get that far, hence no slow down, but we'd get proper float behaviour in other cases. | 11:29.50 |
| simon91 | yeah if we had a fast strtof we could delegate the non-INT cases to it | 11:31.01 |
| tor8 | Robin_Watts: simon91: something like the top commit on tor/master | 11:31.12 |
| | or we can use the same sort of strtof as in the css application once we see the decimal point | 11:31.52 |
| | parse as int up to that point, see the point and punt to float parsing | 11:32.11 |
| Robin_Watts | tor8: parse as an int until we see the point. | 11:33.24 |
| | parse the denominator as an int until it gets too large to fit in an int. Then convert it all to a float and do the rest as floats. | 11:33.53 |
| | The solution on tor/master would be bad. | 11:34.36 |
| simon91 | me thought was to write a fast strtof. Id would work like fz_grisu in reverse. So in a nutshell it take a buffer, say "123456" and an exponent, say "-22". | 11:35.31 |
| | it then converts the "123456" into a diy_fp_t and looks up 10^-22 as a diy_fp_t in a power of the cache | 11:36.25 |
| tor8 | Robin_Watts: it would be better than strtod :) | 11:36.29 |
| simon91 | then multiplies and convert the diy_fp_t to a float | 11:36.51 |
| tor8 | simon91: we don't need that kind of precision here; this code must be *fast* (and is okay to be imprecise) | 11:36.59 |
| simon91 | tor8: i guess that would be fast. Maybe even faster then repeatedly multiplying with 10 using double artihmetic. | 11:38.05 |
| Robin_Watts | I have a tweaked version here. | 11:38.31 |
| tor8 | Robin_Watts: I'm trying the tweaking, but I still have the problem of integer overflow :/ | 11:39.52 |
| Robin_Watts | see the note in the existing code. We want overflow to work the way it currently does. | 11:40.12 |
| tor8 | Robin_Watts: but what about 123450000000000000000678.0 | 11:40.31 |
| | that would return 678.0 now | 11:40.46 |
| Robin_Watts | tor8: That's exactly the case the comment deals with. | 11:40.46 |
| | Yes. | 11:40.50 |
| | And tests show that that's exactly what acrobat does. | 11:40.59 |
| tor8 | Robin_Watts: okay then! | 11:41.07 |
| Robin_Watts | Ok, top commit on my jni2 branch. | 11:41.29 |
| tor8 | Robin_Watts: then top commit on tor/master | 11:41.33 |
| Robin_Watts | (untested) | 11:41.35 |
| | I suspect that if (neg) x = -x is faster than x = sign * x; | 11:42.33 |
| | tor/master looks wrong to me. | 11:43.51 |
| | If I'm reading that right, ALL fractional bits are handled as floats. | 11:44.31 |
| tor8 | they are, for simplicity sake | 11:44.49 |
| | I'd go with the code on jni2 | 11:45.01 |
| Robin_Watts | crap. | 11:45.14 |
| | typo in mine. Just a mo. | 11:45.21 |
| tor8 | the overflow behaviour still bothers me, even if adobe do it! | 11:45.58 |
| simon91 | tor8: if you give 1e13 to gs's pdfwrite it will print it as "1e13" | 11:47.11 |
| Robin_Watts | Ok, test running now. | 11:47.45 |
| simon91 | which is the right number but the wrong format as pdf does not allow exponent format | 11:47.46 |
| Robin_Watts | ugh. | 11:47.56 |
| simon91 | maybe I should file a gs bugreport | 11:48.30 |
| tor8 | simon91: 1e13 is invalid PDF syntax | 11:48.32 |
| | as you just said... *slow reader today* | 11:48.41 |
| Robin_Watts | hmm. something's odd here. I just pulled from golden and stuff won't compile. | 11:50.35 |
| | Where is 'signbit' defined? | 11:51.40 |
| tor8 | Robin_Watts: oh bollocks. | 11:51.49 |
| | #if _MSC_VER < 1800 static __inline int signbit(double x) {union{double d;__int64 i;}u;u.d=x;return u.i>>63;} #endif | 11:52.27 |
| Robin_Watts | ok, that sorts it. | 11:54.17 |
| | cluster test running now (was failing for a different reason on the cluster - out of date submodule). | 11:54.38 |
| | Are you going to do a commit to fix that, or should I ? | 11:54.51 |
| simon91 | If we loose precision while reading in the floats and repeatedly print out and parse in a file the numbers will go more and more astray with each parse/save cycle | 11:55.04 |
| Robin_Watts | urm... should that all be inside #ifdef _MSC_VER ... #endif ? | 11:55.32 |
| | otherwise linux builds will whinge that _MSC_VER is not defined. | 11:55.47 |
| | simon91: yeah. I hope the version I'm testing now should sort the issue. | 11:57.01 |
| simon91 | and with repeatedly calling "fd /= 10" as on jni2 we are loosing precision. | 11:57.05 |
| | a can guarantee you | 11:57.15 |
| Robin_Watts | simon91: Want to produce a better version in the same vein? | 11:57.33 |
| simon91 | if you do not want to use precision there are only 2 ways of doing it afaik | 11:58.28 |
| tor8 | Robin_Watts: yeah. look in thirdparty/mujs/jsi.h | 11:58.49 |
| simon91 | 1) use multi precision arithmetic like most e.g. the glibc strtof does | 11:59.15 |
| Robin_Watts | Ah, right. | 11:59.18 |
| simon91 | this is bad as it's extremely slow. | 11:59.32 |
| Robin_Watts | OK, tests show differences in 22 out of 14808 files. | 12:00.19 |
| tor8 | Robin_Watts: so the cluster failure with mujstest yesterday was an out of date submodule? | 12:00.19 |
| Robin_Watts | tor8: no. | 12:00.30 |
| simon91 | 2) use cached powers of 10 like described above | 12:00.57 |
| Robin_Watts | the first mupdf cluster test I just ran died due to *my* submodules being out of date. | 12:01.00 |
| | simon91: If you want to do a version that uses cached powers of 10, go for it. | 12:01.17 |
| simon91 | ok, the most simple way is to store the powers using doubles. do we have double artihmetic on all target platforms? | 12:02.38 |
| | otherwise I have to use a self made floating point type | 12:03.08 |
| Robin_Watts | simon91: why can't we use floats? | 12:03.15 |
| | yes, we assume the existence of doubles. | 12:03.27 |
| simon91 | the theory says that you need a type with a higher number of bits than the target type. | 12:03.59 |
| Robin_Watts | simon91: So, just to be clear, your new code will only kick in in the 'underflow:' case, right? | 12:04.12 |
| simon91 | yeah sure | 12:04.19 |
| Robin_Watts | cool. | 12:04.23 |
| | simon91: sounds sensible to me then. | 12:04.32 |
| | Actually... given that we are parsing floats... | 12:04.52 |
| | floats have fewer bits in the mantissa than 32bit ints. | 12:05.18 |
| simon91 | yeah you could use a self-made type with a uint32_t as the significand | 12:05.50 |
| Robin_Watts | so we could possibly change the code to skip leading zeros after the . and still use ints to the maximum size of the int. | 12:05.51 |
| | Then we could multiply those ints by a cached reciprocal. | 12:06.20 |
| simon91 | thats exacty what I'm proposing | 12:06.41 |
| Robin_Watts | So we'd only ever end up doing v = (float)i + n * magic[d] | 12:06.55 |
| | simon91: right. being slow this morning, sorry. | 12:07.04 |
| Robin_Watts | scuttles back under the gs stroking rock for a bit. | 12:07.39 |
| simon91 | will need some time to write that up properly. | 12:08.11 |
| Robin_Watts | simon91: In tests on our cluster (which tries 14800 files/resolutions/etc) the change to correctly read the lower bits doesn't make any differences. | 12:09.57 |
| | so, this is a 'nice to have', but low priority change. | 12:10.16 |
| tor8 | Robin_Watts: mujstest fix on tor/master | 13:03.01 |
| Robin_Watts | tor8: looks plausible. | 13:04.08 |
| tor8 | Robin_Watts: fab. and the epub change? | 13:05.13 |
| | takes us from 20s to 17s on one specially problematic file | 13:05.35 |
| | (a 13k page epub) | 13:05.42 |
| | I think the next step would be to convert the CSS rule set into some sort of finite automaton similar to a regex matcher | 13:06.45 |
| Robin_Watts | tor8: looks ok. | 13:07.42 |
| | I think you could probably do better by open coding that function. | 13:08.10 |
| | but the finite automaton might be even better (if I follow what you mean) | 13:09.00 |
| | Is this function still a hotspot? | 13:09.15 |
| | I wonder if it wouldn't be faster/less memory to store convert css stuff into a different format on loading. | 13:12.52 |
| | Anything to avoid string comparisons during layout. | 13:13.10 |
| tor8 | define "open coding" | 13:14.49 |
| Robin_Watts | rather than calling strlen/strcmp, implement them yourself. | 13:15.32 |
| tor8 | there are a *lot* of css properties and until we know the exact set I prefer to keep the flexibility of using a bag of strings | 13:15.34 |
| Robin_Watts | tor8: I'm not suggesting hardcoding a known set of properties. | 13:15.55 |
| tor8 | interning the strings at css parse time and then just use pointer comparisons is probably going to give us a fairly significant speed boost | 13:16.30 |
| | but here we're comparing names in the css selector to xml attributes | 13:16.51 |
| Robin_Watts | I'm saying that when we load css, keep a list of property names we've met so far in a dictionary, and store just the index into the dict (or something like that) | 13:17.17 |
| tor8 | the bag of strings used makes fz_apply_css a minor hotspot (13% vs the 80% or so of fz_match_css) | 13:17.40 |
| Robin_Watts | so fz_match_css is the big one ? | 13:17.59 |
| tor8 | so the matching is the main target for optimization, yeah | 13:18.01 |
| | and the property names don't come into that one | 13:18.07 |
| | only the xml attributes and css selectors | 13:18.18 |
| | compiling the css selector rule set into some kind of regex and using an automaton is going to be needed for any major performance gains | 13:19.10 |
| | grouping all the selectors that begin with matching a 'div' tag once, and only doing that tag name 'div' comparison once for the whole group | 13:19.36 |
| | etc | 13:19.39 |
| Robin_Watts | right. | 13:19.49 |
| | is ordering important ? | 13:19.53 |
| tor8 | sadly it is :( | 13:19.58 |
| | so I'm inclined to just leave this as good enough | 13:20.08 |
| | before I started caching the glyph advances, 75% of the time was spent laying out pages | 13:20.25 |
| | now 75% of the time is spent applying CSS instead | 13:20.35 |
| | on my machine, parsing and laying out a 900 page epub takes < 0.5s | 13:22.15 |
| Robin_Watts | But your machine is a turbo nutter thing. how long would it take on a kindle style device? | 13:22.49 |
| | (I admit that doesn't sound huge though). | 13:23.03 |
| tor8 | long enough to be bothersome but not a show stopper, I hope | 13:23.14 |
| Robin_Watts | I wonder if we could save much time by eliminating some repeated fz_xml_att lookups. | 13:23.26 |
| tor8 | the alternative is to add the notion of chapters to all the viewers, and all navigation positions two-dimensional chapter+page things | 13:23.41 |
| | we could possibly have a fixed attribute slot for 'class', that could speed things up a bit | 13:26.12 |
| | but fz_xml_att is only 1% of the total time | 13:26.19 |
| Robin_Watts | Or we ditch the concept of pages entirely, and have positions become "n of m" | 13:26.34 |
| | for some formats that would correspond to pages. For others, it would correspond to 'words' or something. | 13:26.56 |
| tor8 | and then 'get position of previous page'? | 13:26.58 |
| | and 'get page of position' | 13:27.17 |
| Robin_Watts | yeah. just throwing out random ideas here. haven't thought them through. | 13:27.32 |
| tor8 | so page down would be pos = fz_next_page(ctx, doc, pos) | 13:27.45 |
| | that might work | 13:27.54 |
| | and remove fz_count_pages and just have fz_last_page(ctx, doc) return the final position in the document | 13:30.27 |
| | the 'm' of your idea | 13:30.50 |
| Robin_Watts | fz_max_position. | 13:32.15 |
| | The problem is, when you resize the text, and layout again, you still need to figure out where the start of the page is. | 13:33.23 |
| | which requires relaying out all the pages to the current one. | 13:33.31 |
| | So it doesn't free you from doing the work. | 13:33.54 |
| | Possibly we should add an additional concept of 'position' alongside our current concept of pages. | 13:34.21 |
| | When you do a resize, you get the position from the page, then resize, then get the page from the position. | 13:34.41 |
| | So resizing doesn't lose you the place in the book. | 13:34.54 |
| tor8 | yeah, we have a bit of an ugly hack now: pos = page / pagecount | 13:37.09 |
| | layout and set the page to pos * pagecount | 13:37.17 |
| | having the pos be an accurate position in the html would be better | 13:37.48 |
| | nej | 13:38.11 |
| | bah, wrong window | 13:38.16 |
| Robin_Watts | I can't see a way to avoid the relayout of pages on a resize in order to get page starts correct. | 13:38.49 |
| tor8 | relayout is faster though; all the css rules have already been matched and resolved so it only needs to recalculate the numbers | 13:40.25 |
| Robin_Watts | tor8: Oh, so the slow bit is the initial load? | 13:41.28 |
| | I don't care if it takes 10 seconds to open a book initially. | 13:42.26 |
| tor8 | initial load is about 75%, laying out is 25% | 13:42.29 |
| Robin_Watts | I do care if page flips and or resizing text is huge. | 13:42.44 |
| tor8 | currently page flips are instantaneous | 13:43.09 |
| | resizing text takes 25% of the initial opening a book time | 13:43.20 |
| | FT_Get_Char_Index takes a huge chunk of the layout time | 13:44.20 |
| Robin_Watts | lunches. | 13:44.46 |
| | presumably we could save a 'cached' version of the book back to improve the loading time if we had to ? | 13:45.20 |
| | initial load = 10 seconds, subsequent ones = much faster. | 13:45.59 |
| tor8 | we could cheat by saving page counts of individual chapters at the current layout size | 13:46.27 |
| | and then lazily swap those in, but changing the text size would trigger a full load again | 13:46.42 |
| Robin_Watts | tor8: You say that loading/parsing takes 75% of the time. | 14:44.33 |
| | What I am suggesting is that we have a way to save the parsed version to disc as a 'cache'. | 14:44.53 |
| tor8 | our parsed version is not in a good format for saving to disc | 14:45.15 |
| | it's a tangle of pointers | 14:45.22 |
| Robin_Watts | tor8: ok, but that's something we could potentially think about. | 14:46.10 |
| tor8 | okay, optimizing some of the hot spots have flattened the profile a bit | 14:46.18 |
| | from the profile 70% of the time is in fz_open_document. 5% zip reading, 10% css parsing, 5% xml parsing, 50% 'box generation' | 14:49.54 |
| | in the box generation, there's 15% css matching, 15% css applying properties, 15% malloc (to create the nasty mess of pointers for the box model) | 14:50.42 |
| | 25% total time is for layout, 15% total time is spent converting unicode to glyph indices | 14:51.59 |
| | so that we can look up glyph metrics | 14:52.08 |
| | getting rid of the 15% of malloc using a pool allocator for these nodes would be a good first step | 14:52.53 |
| Robin_Watts | so caching the unicode->glyph lookup might help (especially when you consider that most texts are all one language). | 14:53.17 |
| tor8 | yeah; that's also a possibility | 14:53.39 |
| Robin_Watts | Cache unicode lookups in blocks of 256. Latin will fit entirely within 1 block. | 14:53.56 |
| tor8 | the freetype guts to do that lookup use a binary search on an array | 14:53.57 |
| | I think just caching the first 4k of the unicode range would be okay, and use uncached for everything else | 14:55.05 |
| | that should cover most non-CJK languages | 14:55.13 |
| Robin_Watts | we'd lookup: block = cache_block[code>>8]; if block != NULL glyph = block[code & 0xff] | 14:55.35 |
| | That'd be 256 pointers + the used blocks, and we can cap the maximum number of blocks easily enough. | 14:56.13 |
| tor8 | latin+cyrillic+greek all fit in the first 6 blocks of 256 | 14:56.59 |
| Robin_Watts | yeah, but my solution is barely more complex, need use no more memory, and would cope with japanese, korean, chinese etc too. | 14:58.05 |
| | I'm foolishly keen to try tweaking your code so that it can bidirectional layout. | 14:58.40 |
| | I think that might really make us stand out as a solution. | 14:58.49 |
| tor8 | Robin_Watts: I think that would be a great idea! | 15:00.31 |
| | I'd just have to add some arabic and hebrew embedded fonts to the fallback chain | 15:00.47 |
| | Robin_Watts: let me hack up my solution (it's quick and dirty) and see how much we gain by it | 15:01.11 |
| Robin_Watts | tor8: We might need to start looking at using some libs that know how to cope with the opentype tables etc. | 15:01.42 |
| | so we get glyph shaping etc. | 15:01.51 |
| tor8 | harfbuzz, but I suspect that will be a bitch to build | 15:02.45 |
| Robin_Watts | harfbuzz, yeah. | 15:02.50 |
| tor8 | it's c++ with possible gnome-ish dependencies | 15:02.55 |
| Robin_Watts | or we extract bits from SOTs font engine. | 15:03.13 |
| tor8 | fribidi is simple enough, for basic bidi. and I believe harfbuzz needs bidi to be already done | 15:03.21 |
| Robin_Watts | fribidi is LGPL. No good. | 15:04.46 |
| | There is a non-gnu version out there somewhere... | 15:05.25 |
| tor8 | ah. | 15:05.36 |
| | well, a simple 1328 slot cache to fz_encode_character shaved the layout time from 25% to 15% | 15:06.07 |
| Robin_Watts | tor8: cool. | 15:07.16 |
| tor8 | and bumped the css matching/application and malloc up to 19% each | 15:07.21 |
| | and adding your two-step buffer cache to that should be easy enough to do once we get complaints about slow CJK :) | 15:08.01 |
| | bumping it to 2304 should cover hebrew and arabic as well | 15:08.44 |
| Robin_Watts | mvrhel_laptop, rayjj: In gxclrast.c, we set halftone_type by reading the clist, but we never use it. | 15:31.18 |
| | Why do we bother to send it if it's not used? | 15:31.30 |
| mvrhel_laptop | That is true also with the interpreter | 15:31.45 |
| | In that we set the halftone up always | 15:32.39 |
| | I wonder if there is some relation in that respect. In the clist case though, we certainly should know if its going to be used | 15:33.35 |
| | or not | 15:33.47 |
| | at read time that is | 15:34.03 |
| Robin_Watts | No, I mean, if it's never going to be used, why do we bother wasting space in the clist for it ? | 15:34.56 |
| mvrhel_laptop | Is it not one of those things that you have to have in case you do need it and you don't know until you have read the whole PS file? | 15:35.45 |
| Robin_Watts | mvrhel_laptop: No. It's one of those things where you have an assignment in a C program that says 'fred = 10;' and then you never access fred :) | 15:36.22 |
| mvrhel_laptop | ok. I don't know then | 15:36.54 |
| Robin_Watts | ok :) | 15:37.00 |
| | one for ray when he comes online. | 15:37.09 |
| | Just checking it's not something that we *should* be using and aren't. | 15:37.24 |
| mvrhel_laptop | If the source file has something that needs to be halftoned then we would use it | 15:38.36 |
| | But you might not know until you read the file. Sort of like the spot colors was my thought | 15:39.18 |
| | anyway I don't know. just speculating | 15:40.24 |
| | The install of the halftone always and the use of the pdfwrite device always (even when its not the output device) always puzzled me | 15:41.13 |
| Robin_Watts | mvrhel_laptop: Right, but in that case, I'd expect us to write the halftone_type to the clist, and then use it in some cases, but not others. | 15:46.53 |
| | but we never use it, so there was never any point in writing it to the clist in the first place. | 15:47.19 |
| | (unless it's just there for debugging) | 15:47.26 |
| | chrisl: ping. | 15:53.42 |
| | gx_ttfReader__default_get_metrics has an interesting if (bVertical) clause in it. Does that seem right to you? | 15:54.03 |
| | Should it perhaps be factor = -factor; ? That would be more in keeping with other code. | 15:54.43 |
| HenryStiles | my neighborhood fiber installation was delayed, I have to sit and wait while all my friends are plugged in... bastards ... | 15:55.22 |
| Robin_Watts | yeah yeah, my heart bleeds :) | 16:02.31 |
| | OOH OOH! Supposedly my cabinet is "accepting orders!" | 16:03.27 |
| | for everyone in the street except my house. wtf. | 16:03.43 |
| mvrhel_laptop | thats odd | 16:04.04 |
| Robin_Watts | and this will only be FTTC. | 16:04.06 |
| HenryStiles | they know you ... | 16:04.15 |
| mvrhel_laptop | Robin_Watts: Have you read Ready Player One? | 16:04.20 |
| | I just finished it. It was a pretty fun book | 16:04.32 |
| | bbiab | 16:10.44 |
| Robin_Watts | mvrhel: I have not. Will look. | 16:16.59 |
| | Ok, so they seem happy to take my order. | 16:18.56 |
| | I suspect the web checker is confused by the fact that I brought my phone number with me from the neighbouring village. | 16:19.23 |
| | estimate down = 39.8, up = 10. | 16:19.34 |
| | should start on the 4th feb. | 16:19.46 |
| | So I'll have sympathy for henry in a month :) | 16:20.12 |
| tor8 | Robin_Watts: so are the commits on tor/master good to go? | 16:24.53 |
| Robin_Watts | checking. | 16:25.47 |
| | For the sort properties stuff, does that mean we'll sort on every fz_match_css ? | 16:28.00 |
| tor8 | it does | 16:29.19 |
| Robin_Watts | is it worth a flag to avoid resorting? | 16:29.36 |
| tor8 | still saves us about a second on that huge file that used to take 32s (now takes just about 15s) | 16:29.39 |
| | every fz_match_css runs on a different html node | 16:29.52 |
| | so we never resort the same list of properties | 16:30.05 |
| Robin_Watts | oh, ok, that was my worry. | 16:30.14 |
| tor8 | ideally we'd have a fixed set of known properties with known slots | 16:30.18 |
| | and never even bother with this | 16:30.23 |
| Robin_Watts | ok, all seem reasonable. | 16:31.04 |
| tor8 | great, thanks. | 16:31.20 |
| | with linux 'perf' we get different numbers, match_selector is the main culprit at 25%, and 25% in strcmp | 16:31.53 |
| | I don't think we can do a lot better without re-engineering the css matching engine completely and making everything 10x more complicated | 16:33.24 |
| | but a 100% speed up is reasonable for two days of work :) | 16:33.38 |
| | I still want a pool allocator in mupdf, though. | 16:34.33 |
| mvrhel_laptop | hmm cluster is backed up a bit.... | 16:53.11 |
| Robin_Watts | mvrhel_laptop: mupdf jobs are fast though. | 17:02.37 |
| mvrhel_laptop | yes. plus I get priority... | 17:02.53 |
| chrisl | Robin_Watts: TBH, I think that if (bVertical) thing just shouldn't be there at all - the verticalness of the font should not affect the scale factor there | 17:04.40 |
| Robin_Watts | chrisl: In one of the other functions, it flips the sign of factor, which seemed plausible when I looked at the code referenced in the comment. | 17:08.16 |
| mvrhel_laptop | bbiab | 17:08.27 |
| Robin_Watts | mvrhel_laptop: Bought that book, ta. | 17:08.41 |
| chrisl | Robin_Watts: we might do something like that if we were trying to create fake vertical metrics for a font which didn't contain any, but that would be an icky way to do it - I'll have a closer look | 17:10.13 |
| Robin_Watts | There is a commit on robin/master that ensures some ft_errors are propagated in fapi too. | 17:11.28 |
| chrisl | Hmm, yes, we should check that return value, now this stuff can be called outside of Postscript... that looks fine | 17:16.42 |
| | Robin_Watts: So, doesn't gx_ttfReader__default_get_metrics() end up calling simple_glyph_metrics() via the data.get_metrics method? | 17:18.57 |
| Robin_Watts | chrisl: I dunno. | 17:19.33 |
| | I was just looking at warnings, and the 'factor = factor' was flagged up. | 17:19.53 |
| chrisl | I'll see if I can find a file to exercise it, but I'm fairly sure the inversion is done in simple_glyph_metrics() and all we want in gx_ttfReader__default_get_metrics() is to undo the scaling | 17:22.57 |
| | Huh, the function was genuinely written like that - good grief! | 17:24.17 |
| jogux | SOT has a lot of clever optimised CSS matching stuff (including some of the stuff mentioned, like at layout time we never do any string comparisons), but I don't recall exactly how it all worked | 17:35.30 |
| Robin_Watts | tor8: 2 commits on robin/master (ignore the last one) | 17:45.24 |
| | tor8: Do you have a standard set of epub tests you use for mupdf? Is that online anywhere? Should it be? | 17:54.35 |
| | surely unicode encodings only need to be 16 bits rather than 32? | 17:58.46 |
| | (for our purposes) | 17:58.56 |
| | 3 commits on robin/master then (still ignore the last one) | 18:18.56 |
| chrisl | Robin_Watts: I cannot find a test file that calls gx_ttfReader__default_get_metrics() with bVertical==true. As no one seems to have had an issue with it, and the code has no effect as it stands, I'd just delete it. This was Igor's code, so it's anybody's guess what he meant.... | 18:33.17 |
| Robin_Watts | chrisl: Ok. Did you try nobbling it to crash and then cluster pushing? If not, I will. | 18:33.46 |
| chrisl | I did that locally | 18:34.11 |
| Robin_Watts | You ran every file though it locally? Wow. What PC do *you* have ? | 18:34.43 |
| chrisl | It's pretty quick if you only run one device at one resolution, and only PS/PDF | 18:35.25 |
| | And actually this time I didn't run *all* the files, I filtered it down to only those with Truetype and Type 42 fonts in them | 18:36.44 |
| Robin_Watts | ok, so effectively you've got the same coverage that I'd have doing the test I suggested. I'll not bother then. | 18:37.15 |
| chrisl | Well, as that code can only be called from pdfwrite these days, and is resolution independent, there's no need to run *everything* | 18:38.07 |
| | It *probably* means doing some finicky CIDFont substitution, so I might have a play with that tomorrow | 18:39.30 |
| | But due to some very poor planning on my part, I have to head off again...... | 18:42.59 |
| Robin_Watts | tor8: 4 commits on robin/master (ignore the last one) | 19:04.54 |
| | chrisl: For when you're back: There is a commit on robin/master entitled "Fix some dropped errors in fapi_ft.c". I think you looked at it earlier. | 19:07.09 |
| | We get cluster changes when I test that. | 19:07.22 |
| | The cluster differences are shown in my bmpcmp section. | 19:50.21 |
| mvrhel_laptop | and with that gauntlet in the cluster I think I will take a lunch break | 20:05.25 |
| Robin_Watts | mvrhel_laptop: I've just pushed a commit that should fix the throwback stuff in the IDE. | 20:12.16 |
| mvrhel_laptop | Robin_Watts: great | 20:12.23 |
| | bbiaw | 20:15.49 |
| | Forward 1 day (to 2016/01/07)>>> | |
IRC Logs