| | <<<Back 1 day (to 2020/07/29) | Fwd 1 day (to 2020/07/31)>>> | 20200730 |
| apollo13 | Robin_Watts: interesting fix, does that ensure that the current thread context is used for locking when dropping jbig2_globals instead of whatever was stored? (re http://git.ghostscript.com/?p=mupdf.git;a=commitdiff;h=d50cbc1f593fd86acf20a9d17104ba49e7665719 ). Is this a bandaid or does that fix all the issues you saw in the code? | 07:28.26 |
| sebras | apollo13: I believe that Robin's fix is the correct fix for the crashes you've seen in fz_drop_jbig2_globals_imp(). | 08:22.27 |
| apollo13 | nice, so what does it do? I am always trying to understand the things we work with :) | 08:22.52 |
| sebras | apollo13: the background is that fz_jbig2_globals was allocated and populated by one thread and freed when no longer needed by another thread. | 08:23.07 |
| apollo13 | right and the context you set there now is from "one thread" or "another thread"? | 08:24.44 |
| sebras | apollo13: it is not allowed to use the fz_context belonging to another thread. in this case the call to fz_free() at the end of fz_drop_jbig2_globals_imp() use the correct ctx, but the custom allocator implemented for jbig2dec was using the saved fz_context rather than the current thread's fz_context. | 08:25.11 |
| apollo13 | makes sense, thanks! | 08:26.15 |
| | what I still don't really understand (mupdf is still dark magic for me :D) is why using the wrong context has this affect. Aren't the contexts the same aside from the exception stack? Ie allocation routines etc would be the same? | 08:28.53 |
| | or did an exception happen that caused issues due to the context missmatch | 08:29.23 |
| sebras | apollo13: the exception stack has things pushed and pop on it during normal operation, not just when an exception is throw. | 08:29.57 |
| | thrown. | 08:30.00 |
| | apollo13: so you shouldn't be fiddling around with another thread's exception stack. | 08:30.18 |
| apollo13 | hehe yeah I got that, I was just trying to understand what issue actually popped up. | 08:30.42 |
| sebras | apollo13: will this go into primesign/pdf-as-4? I saw primesign/muRenderer there, but that's implemented in Go so that's not what you're working on. | 08:41.46 |
| Robin_Watts | apollo13: The issue, I suspect is that a thread has ended, and hence its context has been freed. | 10:15.24 |
| | then when that context is used in a different thread, even though the exception stack isn't touched, that context isn't there for it to get the allocators through. | 10:16.07 |
| malc_ | Robin_Watts: another dude criticized the board link to which i posted few days ago, and swears by his kinesis advantage pro 2 with brown switches... he is also an ex ms natural user. | 10:21.24 |
| apollo13 | sebras: ah interesting, didn't know we have/had go stuff (that is certainly old though and not in use). But no, the code we are using here is not yet published and I don't think it would be part of pdf-as-4. | 14:24.18 |
| sebras | apollo13: aha, but likely licensed under AGPLv3 it seems. | 14:58.03 |
| | apollo13: like primesign/murenderer | 14:58.20 |
| apollo13 | sebras: I'd assume so. To be honest I am a sysadmin, so not really my area of expertise. I'll have to ask my colleagues next week, otherwise my answer would just be guesswork. | 15:04.24 |
| malc_ | is FZ_META_ enum for info:CreationDate coming? | 15:19.41 |
| sebras | ator (and malc_): I have successfully built this commit locally: http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=commitdiff;h=37b80439256102c677272ac7155f41d60522918c | 15:36.15 |
| | I don't expect the cluster run to turn bad. | 15:36.37 |
| malc_ | sebras: tack! jeg expectare icke problemare agså | 15:43.59 |
| | if you will excuse my sventalian dialect | 15:44.16 |
| sebras | the cluster run succeeded as expected. now I just need to wait for ator's review. :) | 15:48.54 |
| malc_ | should happen soon enough if recent ator responsiveness is of any indication, it should be real soon now... just a few moments after the second coming i reckon | 15:53.45 |
| Robin_Watts | malc_: Yeah. The layout, shape, tilt of the MS natural keyboard is perfect for me. I just want one with mechanical keys. | 17:29.04 |
| | the kinesis is the best option I've seen, but doesn't look perfect. | 17:29.04 |
| malc_ | Robin_Watts: buy some paint and wake your inner artist up.. | 17:41.54 |
| Robin_Watts | malc_: It's not the "look", it's the "shape", and I can't fix that with paint. | 17:43.26 |
| malc_ | Robin_Watts: buy a blow torch and heat gun and fix it all the same! | 17:47.38 |
| | anyways this ex-colleague of mine has amassed two kinesises already... apparently they grow an people | 17:49.03 |
| avih | i'm not familiar with mupfd (lib), but can it render text with subpixel antialiasing? | 20:11.32 |
| | or even, the blasphemy, enable "slight" hinting in freetype? this would use vertical hints only so the text looks sharper at the vertical edges, while still using "free" positioning horizontally | 20:13.25 |
| | (so that kerning doesn't get fucked) | 20:13.55 |
| | personally, i find current freetype2 slight hinting together with subpixel antialiasing and (currently default) LCD filtering to produce very pleasing results. | 20:17.38 |
| | but mupdf seems to disable any hinting and subpixel antialiasing... | 20:18.01 |
| | i know pdf rendering is about accuracy, but especially when not printed (on paper etc), some tradeoffs in accuracy can yield much greater readability | 20:19.28 |
| | hmm https://ghostscript.com/pipermail/gs-bugs/2016-June/044643.html i disagree with this "We therefore take the view that if you want subpixel rendering, you should update the transform on input to be 3 times as wide, render to a wider pixmap, and then filter it down according to your own specific devices screen." | 20:27.20 |
| | filtering is not trivial, as early freetype subpixel rendering results show (too bright color fringes). | 20:28.03 |
| | it's true that the subpixel orientation needs to be known, but at least with mupdf as a library you can leave this decision to the user of the library | 20:28.47 |
| | additionally, fontconfig does know the preferred orientation (even if gnome for instance maintains its own config outside of fontconfig) | 20:30.06 |
| | and then there's hinting as well. | 20:30.46 |
| | and of course, it doesn't mean the current rendering needs to go away. subpixel and/or hinting type could be options, which i'm very sure some would prefer (and equally sure some would not - and that's fine) | 20:35.17 |
| | all the main OSs today use subpixel antialiasing by default, IMHO because most people find it nicer to look at. | 20:36.16 |
| | <<<Back 1 day (to 2020/07/29) | Forward 1 day (to 2020/07/31)>>> | |
Log of #mupdf at irc.freenode.net.