| | <<<Back 1 day (to 2018/08/15) | 20180816 |
| tor8 | paulgardiner: I can't make heads or tails over how much vertical padding Adobe adds to multiline text fields... | 13:24.08 |
| | it varies based on how tall the field is, but I can't find a common factor based on font size or line spacing | 13:24.57 |
| paulgardiner | I hate strange heuristics like that | 13:26.11 |
| tor8 | it's just plain old voodoo | 13:26.19 |
| | it's not centering it based on the text field height divided by line spacing, either | 13:27.25 |
| | evince looks like it's doing something reasonable, I guess I'll have to go look and see what they do | 13:28.19 |
| | ugh. evince doesn't match Adobe either... but seems to have slightly better magic numbers. | 14:02.50 |
| avih | tor8: hey, re mujs, do i recall correctly that you mentioned that a function which has a try/catch block has some inherent performance impact even if the try block is never entered? | 14:05.26 |
| | if yes, if that implementation details of mujs? or implied by the spec? | 14:06.07 |
| | s/if/is/ | 14:07.07 |
| tor8 | avih: yes, if you use certain language features mujs will not be able to do certain bytecode optimizations for local variable lookups | 14:08.34 |
| avih | you think this inherently applies also to other engines/jit? | 14:09.07 |
| tor8 | creating inner functions with lexical scopes, using 'arguments' and 'eval' and 'with' statements | 14:09.14 |
| | no, this is mujs specific. other engines have other gotchas. | 14:09.24 |
| avih | i see, thanks. | 14:09.35 |
| tor8 | and the 'catch' has an exception variable with its own scoping rules which doesn't play nicely with other local variables, which also disables this optimization | 14:09.50 |
| avih | (wouldn't mind hearing of related gotchas, if you're willing to mention some) | 14:09.54 |
| tor8 | in functions that do NOT use any of the above features in mujs, we don't create a local variable scope object but put locals directly on the stack | 14:11.04 |
| | use of those features however, requires a scope object | 14:11.20 |
| | and scope objects mean local variable accesses are much slower (since they need to do a property lookup in the scope object instead of just popping a value from the stack) | 14:11.48 |
| avih | i see. fwiw, i don't use eval/with, but i (think i) do use function scoping - i do utilize closures, and i don't recall noticing out of the ordinary performance impact (with mujs). | 14:12.25 |
| tor8 | it won't be noticable for most uses, but if you have some heavy numeric loops then it could make sense to wrap them in a function that ends up being in mujs terms 'lightweight' | 14:13.12 |
| | the 'debugger' statement will dump the bytecode of a function, and that also lists whether it is lightweight | 14:14.13 |
| avih | right. never used "debugger", though i do vaguely recall it. i might try it some time :) | 14:14.52 |
| | (not that i have specific performance complaints with mujs. i think it generally does very well for the tasks i've put it to) | 14:15.25 |
| | i was just wondering in general for the try/catch block for some node code. | 14:15.49 |
| torz | avih: in practice it just means that local variables will have the same cost to access as global variables | 14:15.54 |
| | where for lightweight functions they can be faster, in certain cases | 14:16.05 |
| avih | k. i might try to profile that at some point, just to get a sense of the scale of diff. though not right now. | 14:17.17 |
| | also, i currently have no sense of how much variable access speed has an impact on the bigger picture. e.g. before you applied that new number parsing code just doing arr[1] was terribly costly, and until not long ago sort could be very costly, etc. so i have no sense of how much impact variable access has in the big picture | 14:20.42 |
| | (assuming variable lookup speed is the main perf impact of using eval/with/try/arguments) | 14:24.05 |
| | (and generally i do use global symbols extensively) | 14:25.10 |
| tor8 | avih: if you use globals extensively, you won't notice anything different from a lightweight function | 14:35.49 |
| | all it does is speed up local variable accesses | 14:35.56 |
| paulgardiner | I have an encrypted file that mupdf can display, but something goes wrong when I try mutool clean "warning: aes padding out of range" and "invalid string length for aes encryption". I wonder if we now try to maintain the encryption even when cleaning. | 14:39.02 |
| tor8 | paulgardiner: we do try to keep encryption. it's a feature you asked for :) | 14:40.06 |
| paulgardiner | I'd never considered how it would affect clean. I tend to use clean to make the detail of the file readable. | 14:41.43 |
| | In any case, the resulting file wont open | 14:42.11 |
| tor8 | can it wait for Robin? | 14:46.34 |
| | I wanted a flag to mutool clean to strip encryption, but that was voted down :( | 14:47.05 |
| paulgardiner | Sounds like a good feature to have. Yeah, no hurry. | 14:47.34 |
| tor8 | paulgardiner: another good feature would be to add new encryption :) | 14:48.02 |
| paulgardiner | I'm trying to understand why AR is treating some groups of checkboxes as radios, whereas we don't. I've been assuming it's because AR is using the XFA version of the form. I couldn't see the radio flag set in the Acroform. | 14:49.11 |
| | And we often do honour radio groups correctly. Just some cases we don't | 14:49.38 |
| tor8 | ugh. yeah, there are probably lots of lurking issues where PDF files have duplicated forms in AcroForm and XFA | 14:50.13 |
| paulgardiner | You'd hope that most tools that created both forms would get the radio bit right though, I'd have thought. | 14:50.53 |
| tor8 | there are two potential fixes for the latest form issues on tor/master. hopefully they don't cause other files to break... | 14:51.10 |
| paulgardiner | I can give them a try. | 14:53.32 |
| | Fairly limited test, but those seem to work really well. Fixes two bugs and seems not to break anything. | 15:15.16 |
| | Nice | 15:15.21 |
| | tor8: I wonder with form flags whether we should be oring through the inherited ones rather than looking for the lowest place in the hierarchy that has flags | 15:22.06 |
| | Still wondering why some radio buttons don't work. | 15:22.35 |
| | ... although in at least on case Iooked at there wasn't a hierarchy. | 15:23.09 |
| | s/Iooked/I looked/ | 15:24.09 |
| avih | tor8: in mujs (or ES5?) when x="foo"; y=x, y is a reference to an immutable reference counted "foo", right? | 15:43.13 |
| | (and x too, yes) | 15:44.03 |
| | +? | 15:44.11 |
| | or maybe it's duplicated for short strings and ref counted for longer ones? | 15:45.04 |
| | ref* | 15:45.08 |
| lindhe | Hi. I have a PDF that does not render correctly in mupdf. Where do I start to debug? | 19:00.04 |
| | (renders fine in evince) | 19:00.19 |
| | I found the bug tracker! I'll post there! | 19:11.39 |
| sebras | lindhe: https://bugs.ghostscript.com | 19:15.15 |
| tor8 | avih: all strings are immutable. how they are stored is a black box. | 21:36.07 |
| | mujs does not use reference counting, it has a garbage collector | 21:37.51 |
| | Forward 1 day (to 2018/08/17)>>> | |
Log of #mupdf at irc.freenode.net.