| | <<<Back 1 day (to 2013/03/20) | 2013/03/21 |
| Robin_Watts | ray_laptop: you here? | 00:04.41 |
| ray_laptop | Robin_Watts: yes | 00:06.00 |
| Robin_Watts | Did you see my earlier burblings about gc and the gs_state->halftone ? | 00:06.22 |
| ray_laptop | yes, but I didn't really look at it. Just a minute... | 00:06.48 |
| Robin_Watts | I just wondered if you had any instant idea about it. | 00:07.07 |
| ray_laptop | so, by "marking through", do you mean tracing the gs_state, marking objects which are enumerated by the gs_state ? | 00:08.30 |
| Robin_Watts | Yes. Line 878 of igc.c | 00:09.29 |
| ray_laptop | line 878 does not say if (o_is_unmarked(ptr)) which you mentioned in the logs, but I see: if (!ptr_struct_mark(&nep, pstate)) | 00:14.14 |
| Robin_Watts | right, and in ptr_struct_mark, it leads to if (o_is_unmarked(ptr)) | 00:14.47 |
| ray_laptop | Robin_Watts: in line 1088 I see: if (!o_is_unmarked(ptr)) -- not exactly what you mentioned in the logs: if (o_is_unmarked(ptr)) | 00:16.18 |
| | but close :-) | 00:16.34 |
| Robin_Watts | Sorry, probably a typo on my part. | 00:16.38 |
| | The entire object header looks sensible to me. | 00:16.49 |
| | size, type, reloc etc. | 00:17.11 |
| | well, size, and type at least. | 00:17.36 |
| ray_laptop | OK. so the pointer isn't pointing at the expected place, but offset by some amount ? | 00:17.44 |
| Robin_Watts | oh, and reloc. | 00:17.51 |
| ray_laptop | Robin_Watts: or do you think valgrind is confused somehow ? | 00:18.16 |
| Robin_Watts | ray_laptop: The pointer points to the halftone, as expected. | 00:18.18 |
| | and the object header is before that, and that looks reasonable. | 00:18.31 |
| | So it looks to me like valgrind is being confused about the the value being uniniitalised. | 00:18.53 |
| ray_laptop | Robin_Watts: OK. | 00:19.05 |
| | I wonder why ? | 00:19.11 |
| Robin_Watts | On obj_header_data_s, there is some bitfield stuff. | 00:19.21 |
| | In obj_header_data_s, there is some bitfield stuff. | 00:19.29 |
| ray_laptop | Robin_Watts: have you tried valgrind on a DEBUG build -- with -Z@$? on that file | 00:19.48 |
| Robin_Watts | What is the: unsigned _:1, smark:obj_mb_bits; about? | 00:19.51 |
| | I haven't tried those flags, no. | 00:20.11 |
| | I can't see us ever accessing _ | 00:20.25 |
| ray_laptop | Robin_Watts: got me there -- that's some of Peter's magic stackless GC trace magic, AFAIK | 00:20.34 |
| Robin_Watts | hmm. Maybe he's assuming that _h.alone will be in the same place as _m._ will be. | 00:22.05 |
| | I didn't think you were allowed to assume anything about the order of bitfields | 00:22.31 |
| | I bet valgrind is thinking that some of the bits are undefined. | 00:24.57 |
| | I'm going to risk my sanity by trying to understand this tomorrow. | 00:25.15 |
| ray_laptop | Robin_Watts: isn't that the point of bitfields ? to define the order. But that applies to bitfields in a struct -- unions are a different matter | 00:25.16 |
| Robin_Watts | ray_laptop: No. The point of bitfields is to allow space efficient storing. | 00:25.37 |
| | K&R is at pains to say that the order and packing of bitfields is implementation dependent. | 00:25.56 |
| ray_laptop | those are some pretty yucky macros and structs/unions | 00:26.36 |
| Robin_Watts | It then goes on to say that the ANSI standard makes it even more implementation dependent, and so people should read everything about bitfields as being implementation dependent qithout qualification. | 00:26.39 |
| | ray_laptop: Damn straight. | 00:27.58 |
| | ray_laptop: with respect to 693178... is it possible to say "only check for this optimisation if my device is capable of coping with devn color" ? | 00:32.22 |
| ray_laptop | Robin_Watts: so you think that we are just lucky that all of the compilers we've encountered implement bitfields consistently ? Seems a bit unlikely | 00:32.24 |
| Robin_Watts | ray_laptop: I suspect that all compilers pack bitfields always either MSB or LSB. | 00:33.04 |
| | so peters code is fine. | 00:33.15 |
| ray_laptop | Robin_Watts: well, it actually isn't that the device isn't capable -- just that the color type's dc_write proc (for clist serialization) doesn't let it write | 00:33.46 |
| Robin_Watts | I suspect that valgrind is being upset by the use of bitfields. | 00:34.07 |
| | So we should disable the optimisation for some subset of color types ? | 00:34.27 |
| ray_laptop | so the "default" code is supposed to "simplify" it by doing the pattern differently | 00:34.38 |
| Robin_Watts | If we had a "can this color type be serialised" call, we could intelligently pick whether to do the optimisation or not ? | 00:35.51 |
| ray_laptop | Robin_Watts: let me mull that over. That's a good idea, I think. It will prevent most devices from being impacted (in case the optimization was actually more useful than I think) | 00:35.52 |
| Robin_Watts | ray_laptop: Or change the code to scribble 0's into the mask when the optimisation hits, and then clusterpush to see how often we encounter files like that? :) | 00:36.55 |
| ray_laptop | Robin_Watts: we can check if (pdevc->type->write == gx_dc_cannot_write) | 00:39.20 |
| | Robin_Watts: Well, that's a way to see how many times it is encountered -- change the data to write at least 1 bit of '0' and then don't optimize | 00:40.14 |
| Robin_Watts | ray_laptop: exactly. | 00:40.23 |
| ray_laptop | Robin_Watts: trying that now. | 00:58.02 |
| | want to place any bets ? | 01:02.04 |
| | I think the number of times that a pattern ends up being solid will be quite rare, and then only at low res, so the files run so fast it won't matter anyway | 01:03.30 |
| Robin_Watts | possibly, yes. | 01:04.10 |
| | but is there also the case where we have a very small pattern that's repeated a lot ? | 01:04.33 |
| ray_laptop | back in 1993 or before when this probably was introduced, it might have mattered | 01:04.46 |
| | Robin_Watts: there is code to replicate patterns up to 32-bits iirc | 01:05.14 |
| | at least in X | 01:05.23 |
| | Robin_Watts: also halftone tiles (where it is fairly likely) | 01:05.50 |
| | I'm not sure about colored patterns, however | 01:06.21 |
| | bbiaw | 01:08.37 |
| chrisl | Robin_Watts: ping | 12:27.47 |
| kens | fascinating bug fix chrisl, congratulations on that one | 12:32.59 |
| kens | lunches | 12:33.20 |
| Robin_Watts | chrisl: pong | 13:24.45 |
| | Alas, chrisl's fix doesn't explain the valgrind warning I'm seeing. | 13:27.10 |
| Robin_Watts | grabs lunch. back in a bit. | 13:27.21 |
| henrys | chrisl:nice - but watch out you are going to own the memory code if you keep this up. | 13:44.44 |
| | jeez there is some bug in gnu indent that put a blank line after every local variable declaration, I used the same parameters in C-style.htm, must be an introduced problem. | 13:50.20 |
| tor8 | Robin_Watts: so where are we ith the ubuntu discussions? | 14:18.15 |
| Robin_Watts | tor8: No replies as yet. Waiting for the meeting this evening. | 14:18.41 |
| henrys | Robin_Watts: can you send an email to tech about the meeting time tonight or if you want I can do it. Others may be interested. | 14:20.58 |
| Robin_Watts | henrys: 4:30EST tonight in #ubuntu-touch-meeting. I'll send an email. | 14:21.39 |
| henrys | should be EDT | 14:21.58 |
| chrisl | Robin_Watts: what I was going to say was that now I've cleared up the three GC problems I acquired at the meeting, I can look at the valgrind warnings if you want shot of them | 14:29.53 |
| Robin_Watts | Let me continue to look for a bit. If I don't get anywhere I'll hand them off. | 14:30.19 |
| chrisl | 'Kay | 14:30.28 |
| Robin_Watts | y | 14:30.37 |
| chrisl | henrys: I don't mind doing GC problems, as long there isn't much time pressure on them........ | 14:30.59 |
| henrys | chrisl, Robin_Watts:I've been playing with the valgrind gdb server really nice, basically run gdb and it breaks on a valgrind error, a little more flexible than the previous setup where you could just invoke gdb when a problem happens | 14:34.09 |
| Robin_Watts | henrys: ooh, that does sound nice. | 14:34.28 |
| chrisl | henrys: that sounds interesting, I've been meaning to look at it, but never got around to it | 14:34.54 |
| Robin_Watts | henrys: Any useful links on how to install/use it ? | 14:35.14 |
| henrys | let me find it. | 14:35.27 |
| | http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver | 14:36.08 |
| Robin_Watts | henrys: Interesting. If that works with ddd, so much the better. | 14:39.02 |
| henrys | it work with emacs which uses --annotate option to communicate with gdb don't know about ddd | 14:39.32 |
| chrisl | Robin_Watts: all you should need to do is enter the gdb command in the gdb prompt window in ddd | 14:39.45 |
| Robin_Watts | should look into emacs and gdb. | 14:40.14 |
| chrisl | shudders at the very thought of emacs...... | 14:40.31 |
| henrys | Long ago I used to debug in a terminal - but I can't imagine doing it now. sort of like going back to a modem or something. | 14:41.52 |
| chrisl | Yes, but emacs? For something so entrenched in Unix mythology it always seemed totally against the unix philosophy to me | 14:42.54 |
| henrys | chrisl:at my old company most folks debugged in emacs but used vi or other editiors | 14:43.08 |
| | editors | 14:43.12 |
| | i.e. debugging in emacs doesn't require much emacs foo. | 14:44.43 |
| Robin_Watts | vi. The hairshirt of computing for 30 years. | 14:44.57 |
| henrys | and I find ddd aesthetically revolting | 14:45.11 |
| Robin_Watts | mostly uses gdb in a terminal. | 14:45.23 |
| chrisl | Motif was never the prettiest toolkit! | 14:45.33 |
| Robin_Watts | cos ddd is grim. | 14:45.36 |
| henrys | Robin_Watts: It is hard for me to imagine you wouldn't see emacs a big improvement over that. | 14:46.10 |
| chrisl | Whilst ddd is indeed grim, I find it less so than cgdb...... | 14:47.59 |
| kens | much prefers ddd to gdb | 14:48.40 |
| Houl | (gswin32c) I want to merge several pdf files into one ... keeping the exact quality of images (mostly JPGs, a few PNGs) .. how to do that? | 14:50.41 |
| kens | Depends what you mean, the short answer is don't use pdftk | 14:51.11 |
| henrys | gdb is a great debugger, unfortunately Xcode is the only decent client IDE | 14:51.18 |
| kens | is don't, use pdftk | 14:51.20 |
| chrisl | henrys: does Xcode let you access the gdb command line? | 14:51.51 |
| henrys | chrisl:yes | 14:52.00 |
| Robin_Watts | henrys: That's damning with faint praise. Xcode is unusable. | 14:52.03 |
| Houl | kens: so far I've tried gswin32c -dNOPAUSE -sDEVICE=pdfwrite -sOUTPUTFILE=merged.pdf -dBATCH -dPDFSETTINGS=/prepress input1.pdf input2.pdf | 14:52.33 |
| | it's still compressing | 14:52.36 |
| | (I don't yet understand all given options) | 14:53.02 |
| Robin_Watts | Houl: No tweaks you give to gs will prevent it uncompressing and recompressing images. | 14:53.06 |
| | There is no mechanism for passing images through unchanged. | 14:53.19 |
| Houl | Robin_Watts: are there any tweaks? | 14:53.24 |
| | Robin_Watts: hmm | 14:53.34 |
| | so the answer is: don't use ghostscript | 14:53.53 |
| | ? | 14:53.58 |
| kens | yes, use pdftk | 14:54.00 |
| Robin_Watts | Houl: As kens said earlier, yes. | 14:54.07 |
| Houl | ok, thanks. | 14:54.41 |
| henrys | Robin_Watts:I didn't look very carefully but last I checked it was similar to M$ debugging. Why is it unusable? | 14:55.11 |
| chrisl | I *really* dislike the MS debugger - this is all about what you're used to, though | 14:55.41 |
| Robin_Watts | henrys: Everything about Xcode is horrible. | 14:55.51 |
| chrisl | Because it comes from Apple? | 14:56.12 |
| Robin_Watts | You know the past 30 years of shared computing experience that influences how your expectations of things should work? the names you use for things? the way of organising stuff? Well, fuck all that, we're Apple, and we're going to be different. | 14:56.47 |
| chrisl | Robin_Watts: I feel similarly about MS - although Apple seem to have more over a shorter period, on that front | 14:59.23 |
| henrys | Robin_Watts: of late it seems to be working for Apple. | 14:59.46 |
| Robin_Watts | chrisl: I was reluctant to embrace VS, but actually, it behaves pretty much exactly as I'd want it to. | 15:00.00 |
| | Admittedly, that might be because it's been my debugging platform of choice for years, but I never remember any "WTF?" moments with it. | 15:00.29 |
| chrisl | Robin_Watts: like I said, it's just what you're used to - I'd probably get on okay with VS if I used it regularly | 15:00.41 |
| Robin_Watts | I'd probably find Xcode OK if I could only persuade it just to start the damn thing I want it to with the args I want without it having to be wrapped in some horrible Xcode project. | 15:01.32 |
| | https://sourceforge.net/projects/ghostscript/?source=directory: That points to svn.ghostscript.com and the license is GPLv2 there. | 15:04.08 |
| chrisl | In VS, I find having command line options for the target exe buried in the project options unspeakably annoying - largely because gs is so command-line-centric | 15:04.18 |
| Robin_Watts | I'd change it, but I'm not an admin. chris, giles, ray and miles are. | 15:04.38 |
| chrisl | I need to work out *how* you change it - it just finished upgrading the project..... | 15:05.04 |
| Robin_Watts | yeah, that's why I was looking :) | 15:05.16 |
| chrisl | Is there anything visible from the "outside" as a result of the upgrade? | 15:05.46 |
| Robin_Watts | We have 2 thumbs down reviews on sourceforge. The first says "Excellent application! Nice and easy to use." and the second says "good app, always use it for my postscript files. thank you, guys!" | 15:06.25 |
| | chrisl: nafc, sorry. | 15:06.38 |
| chrisl | ;-) License should be right now | 15:06.56 |
| Robin_Watts | license is indeed right. | 15:07.11 |
| chrisl | Huh, the current version is listed as 9.05..... | 15:08.08 |
| docampo | Hi, anybody available to give me a hand on Android? | 15:10.45 |
| Robin_Watts | docampo: Go for it. | 15:12.16 |
| docampo | Ok, here is the situation: On the muPDF Activity , I am implementing onConfigurationChange, to not "re-create" the activity when switching between landscape/portrait | 15:15.18 |
| | I this method, I do the following, in order to refresh the view: | 15:16.26 |
| | pageAdapter.notifyDataSetChanged(); | 15:16.35 |
| | mDocView.setAdapter(pageAdapter); | 15:16.41 |
| | The view is actually being refreshed, but for some reason, the render is not complete. Say, 70% of the page is rendered as it should, and the rest is rendered but as it would be in "low quality" | 15:17.48 |
| | I don't know if I am being clear. | 15:18.07 |
| Robin_Watts | docampo: We render in 2 phases; first a scaled view of the cached bitmap, then a 'high quality' redraw that should make everything sharp. | 15:18.42 |
| | Is it possible that the high quality redraw is being done with the old orientation? | 15:18.57 |
| | so that when that completes what you see as being properly redrawn is actually the intersection between the old and the new visible areas? | 15:19.22 |
| docampo | That could be possible. | 15:19.25 |
| Robin_Watts | That would be about 70% of the screen, I guess. | 15:19.37 |
| docampo | Yes, I think that could be the situation. How could I solve this? | 15:19.51 |
| Robin_Watts | So, I'm guessing that the high quality redraw is being kicked off before the details of the screen size change have made it down that far. | 15:20.13 |
| | I think you need to ensure that the details of the screen size change get passed down before starting the HQ redraw :) | 15:20.50 |
| | It's been way too long since I coded this stuff (and paulgardiner has changed the structure of the app since then) for me to be able to give you a clearer answer than that off the top of my head. | 15:22.19 |
| docampo | How can I ensure that? I think that "getPageSize" is being called, and returning the correct size. Is there any other thing that I should take into account? | 15:22.21 |
| | And, when the HQ redraw start? | 15:23.26 |
| Robin_Watts | getPageSize is to do with the document page size. That won't change when you rotate the device. | 15:24.21 |
| | Its the size of the screen to which we are redrawing that needs to change. | 15:24.37 |
| docampo | Ah, got it. But I am not sure I understand how can I control that. | 15:25.20 |
| Robin_Watts | drawPage is the thing that does the redraw. | 15:25.35 |
| paulgardiner | docampo: in PageView, the ImageView called mPatch has a size dependent on the screen size. Those would need to be recreated. | 15:25.49 |
| docampo | Thanks, Robin_Watts and paulgardiner, I'll take a look. | 15:27.07 |
| paulgardiner | I say those because each PageView will have a subview called mPatch. | 15:27.16 |
| Robin_Watts | docampo: Can I ask why you are wanting to stop the activity being restarted on a rotate? | 15:27.46 |
| paulgardiner | There could be many values within ReadView that need recalculating. It's difficult to predict. | 15:27.50 |
| Robin_Watts | I wasn't aware that was even an option :( | 15:27.56 |
| docampo | I have to do some stuff when rotation change. Also, there is some stuff on the onCreate method that shouldn't happen any time the user rotates the device. | 15:29.08 |
| Robin_Watts | docampo: Such as? | 15:29.40 |
| docampo | BUT, I could figure out a way to re-create the view and avoid doing that stuff I need to do just once. | 15:29.41 |
| Robin_Watts | Oh, right, *your* app has stuff that mustn't be done repeatedly, sorry. | 15:30.06 |
| docampo | yes | 15:30.18 |
| | This stuff, on a "low range" device, was throwing an OutOfMemoryError | 15:32.26 |
| | could it be that onMeasure is not being called? Or something related to it? | 15:38.41 |
| paulgardiner | You may need to trigger a layout, although I'd have expected the system to do that for you. | 15:39.59 |
| Robin_Watts | paulgardiner: If he's trapping the rotation event, maybe not? | 15:41.01 |
| | Are you going to end up in the situation where the top bar doesn't move? | 15:41.33 |
| docampo | I'm not following you, which top bar? | 15:43.09 |
| Robin_Watts | In the file picker view, you can still see androids top bar. | 15:47.42 |
| | chrisl: OK. I'm going to run screaming from this valgrind problem, at least for now. | 15:53.08 |
| chrisl | Robin_Watts: okay, can you give me a file and command line to reproduce the problem exactly? | 15:53.42 |
| Robin_Watts | valgrind --db-attach=yes --track-origins=yes debugbin/gs -sDEVICE=tiffscaled -dDownScaleFactor=3 -r600 -o out.tif /mnt/hgfs/artifex/ghostpcl/tests_private/comparefiles/Bug690025a.pdf | 15:54.14 |
| docampo | Just to let you know, I think I got it fixed: it was that on the configChanges properties, I was managing to "screenSize". I needed to do this on the past because some Android version requires this to fire onConfigurationChange. | 15:54.34 |
| | But for now, it seem to be working. | 15:54.49 |
| Robin_Watts | docampo: OK. fair enough. | 15:55.07 |
| | Can I ask what sort of app you are developing? | 15:55.17 |
| chrisl | Robin_Watts: Cool, I'll look at it tomorrow. FWIW, I think there is a fundamental issue in that we don't seem to initialize the gc flags for new "st_-type" allocations | 15:55.53 |
| Robin_Watts | chrisl: I've added various memsets to try forcing flags to 0 for objects, and that seemed to shift the problem slightly. | 15:56.39 |
| | The current one I'm seeing is a block of bytes. | 15:56.58 |
| chrisl | Robin_Watts: yes, the one I looked at I got down to two warnings, and the valgrind's "track origins" output was buggered.... the line it pointed to didn't have an allocation nor a variable declaration (in fact, I think it was white space.....) | 15:58.27 |
| | tor8: we're not automatically pulling commits across from ghostpdl to the jbig2dec repo - should we be doing so, or is there a reason you left it? | 16:03.30 |
| ray_laptop | chrisl: I want to add my admiration for digging out that obscure path memory issue. Any tips on what techniques you use ? I tend to get stuck using the methods I've always used and you may have a different approach that might help. | 16:04.33 |
| chrisl | ray_laptop: thanks - I have to admit, that last one was a b*stard! | 16:11.17 |
| ray_laptop | Robin_Watts: BTW, the test to detect how often the pattern optimization was used came up with over 2000 "hits". Even allowing for multiple hits due to the same test file, just different devices, I decided to leave it in | 16:13.08 |
| Robin_Watts | ray_laptop: Seems sensible. | 16:13.32 |
| ray_laptop | Robin_Watts: I found a way to 'revert' the case down to devn_fill_rectangle | 16:13.55 |
| chrisl | ray_laptop: As for techniques, I don't think I have any special tricks - I have a surprisingly good memory for things that interest me. The thing I find helps the most is to get clear in your head the layout of objects and their contents in memory - I don't mean the entire memory layout, but where the headers are, and the various mark/reloc variables. Then you can quickly inspect their values for a given object. | 16:15.19 |
| tor8 | chrisl: I have a crontab job that should pull across daily | 16:16.35 |
| chrisl | tor8: I only see a cron entry for updating the mupdf third party libs | 16:17.18 |
| | ray_laptop: From a psychological perspective, I also like to keep reminding myself that there's nothing "magic" in there - it just seems that way because of all the crazy macros. What the garbage collector does is really very simple, it's the macros and the sheer number of objects that make it difficult to decipher. | 16:18.42 |
| | ray_laptop: does the Visual Studio debugger expand macros for you? | 16:20.30 |
| Robin_Watts | chrisl: The problem I most often find is that I want to track what happens to a given object back in time. | 16:21.05 |
| ray_laptop | chrisl: no, but it has a "Go to Definition" right mouse action | 16:21.28 |
| Robin_Watts | i.e. I want to find out when a given object was allocated, or when it was reloced there etc. | 16:21.28 |
| chrisl | Robin_Watts: I tend to work the other way - I work out what type of object it is, find which instance causes the problem, then work *forward* from the creation | 16:22.37 |
| ray_laptop | darn. have to reboot. Windoze is confused and thinks a file that doesn't even exist is still locked | 16:22.39 |
| Robin_Watts | ray_laptop: handle ? | 16:23.01 |
| | Bah. There is a sysinternals tool for closing handles. | 16:23.29 |
| ray_laptop | I use conditional breakpoints (or sometime add in C code) to spot the enumeration or relocation of a certain address. | 16:23.32 |
| chrisl | ray_laptop: gdb has a "macro expand" command, which completely expands a macro for you - makes things easier | 16:24.04 |
| ray_laptop | gdb is much nicer than windows because the addresses are always different. They stay the same in repeated gdb runs | 16:24.07 |
| Robin_Watts | ray_laptop: In procexp you can "Find" a handle. | 16:24.19 |
| ray_laptop | chrisl: what's the gdb command ? | 16:24.29 |
| Robin_Watts | Then you can close it. | 16:24.31 |
| chrisl | ray_laptop: macro expand <macro> | 16:24.44 |
| ray_laptop | too obvious. Thanks, chrisl | 16:24.57 |
| chrisl | obviously you have to give it the parameters, too | 16:25.13 |
| | Robin_Watts: you can work "backwards" tracing an object by judicious use of conditional break points in the enum_ptrs and reloc_ptrs functions | 16:29.39 |
| | ray_laptop: so, for example: "macro expand ref_assign(a,b)" gives "expands to: (*(a) = *(b))" | 16:31.10 |
| Robin_Watts | chrisl: For non GC stuff, I use memento, as that labels each block with a sequence number, so it's easy to follow that. | 16:31.16 |
| ray_laptop | Robin_Watts: right. That's why a debug chunk allocator has that feature as well. | 16:31.43 |
| | non GC stuff is mch easier | 16:31.58 |
| Robin_Watts | I daresay there is a set of -Z flags that will output all the details of allocations/relocs etc, so I could trace it through that, but.... | 16:32.11 |
| ray_laptop | Robin_Watts: exactly. Unless it's a VERY simple case, the amount of debug is daunting. | 16:32.45 |
| chrisl | Robin_Watts: yes, that is a great help. I have thought about adding something like that to the GC data for debug builds - not sure how it would work, though. | 16:32.57 |
| ray_laptop | but I sometimes set the gs_debug[] elements after breakpoints to cut it down | 16:33.26 |
| Robin_Watts | chrisl: can we just stick an "int sequence" into obj_header_data_t ? | 16:34.13 |
| ray_laptop | chrisl: that's a good idea. An object sequence number would help track objects | 16:34.28 |
| Robin_Watts | The IGC_PTR_STABILITY_CHECK stuff seems to put extra stuff in there. | 16:34.55 |
| chrisl | Robin_Watts: we'd have to make sure that it got copied to new locations when we did a reloc - that was the bit I wasn't clear on | 16:35.00 |
| ray_laptop | why didn't I think of that 20 years ago ? | 16:35.09 |
| Robin_Watts | chrisl: presumably either it will happen magically, or hunting for IGC_PTR_STABILITY_CHECK will find code that copies that bit ? | 16:35.55 |
| ray_laptop | chrisl: see -- that's why I wanted to chat about how you do things. Helps me unfreeze the gray cells | 16:35.59 |
| chrisl | Robin_Watts: I don't think it will happen magically, because I don't think we copy the header contents around, but maybe the ptr stability stuff would. I don't think it's a huge deal, I just never had the chance to sit down and investigate properly. | 16:37.20 |
| | The other issue is Postscript refs - they might need special handling | 16:38.25 |
| | Robin_Watts: Actually, I think one thing that made me cautious about it was that I was concerned that the might be places in the code that assume the header is a given size, and that would be a pain (as well as *really* bad) | 16:41.07 |
| Robin_Watts | chrisl: Right, but the IGC_PTR_STABILITY_CHECK would seem to indicate that that isn't the case. | 16:41.36 |
| chrisl | Robin_Watts: I admire your optimism...... | 16:41.58 |
| Robin_Watts | My optimism is essential. If I learnt from mistakes, I'd never attempt anything... | 16:44.16 |
| chrisl | It does look eminently doable - I'll do it as a mini-project, if we think it would be useful - and it seems we do. | 16:46.11 |
| Robin_Watts | chrisl: It sounds useful to me. | 16:47.07 |
| chrisl | I'll make a start tomorrow - if we're right, it shouldn't take long at all. If we're wrong....... | 16:47.47 |
| | Robin_Watts: I'd thought of just simple, incrementing id - is that what mememto does? | 16:49.19 |
| Robin_Watts | chrisl: Exactly. | 16:49.31 |
| ray_laptop | chrisl: that's what the chunk allocator does | 16:49.37 |
| chrisl | Good, I like simple :-) | 16:49.41 |
| Robin_Watts | Memento has functions you can call from the debugger to tell it to stop when we reach certain allocations, or to find a given block by id number etc too, but that's just icing on the cake. | 16:50.27 |
| | Memento increases the id on frees too, so the number isn't "how many allocations have we done", it's "how many allocation events have there been" | 16:51.13 |
| chrisl | Hmm, that could be harder because of the way GC "frees" memory, but we'll see | 16:51.53 |
| | I think just being easier to identify that "this is the object of interest" will be a big benefit | 16:52.48 |
| Robin_Watts | chrisl: Indeed, it may not be appropriate here. | 16:53.54 |
| | Except maybe to have all gcs count as 'an allocation event'. | 16:54.29 |
| chrisl | Actually, it must be easy enough because -Z@ fills gc'ed memory with a different pattern to freed memory | 16:55.17 |
| Robin_Watts | It'd be nice if the object numbers were mentioned in the debugging, but that's a tedious task. I could help with that if required. | 16:55.28 |
| chrisl | Robin_Watts: once the infrastructure is in place, it should be easy enough to tweak as we work with it | 16:56.06 |
| Robin_Watts | yeah. | 16:56.12 |
| | paulgardiner: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=bfb6ba336570817182082ce3badd5f80863e01c4 | 16:56.54 |
| chrisl | I'd do it now, but I have to finish shortly - squash training, and then a league match - what was I thinking?!?! | 16:57.16 |
| Robin_Watts | ouch. | 16:57.29 |
| paulgardiner | Robin_Watts: just looking | 16:58.10 |
| | :-) | 16:58.21 |
| chrisl | If I'm playing well, the training will help - if I'm playing badly, I'm buggered either way | 16:58.34 |
| Robin_Watts | eek. | 17:00.14 |
| | paulgardiner: Stupid typo in that commit. | 17:00.36 |
| paulgardiner | return 0 ? | 17:00.49 |
| Robin_Watts | yeah. | 17:01.39 |
| paulgardiner | Ah! I'm a little worried about stalling the UI. I think countPages is something we otherwise do only in the background. | 17:03.31 |
| Robin_Watts | paulgardiner: OK... | 17:03.53 |
| | We seem to do it in various different places. | 17:04.10 |
| tor8 | chrisl: the mirror-thirdparty.sh script also does jbig2dec | 17:06.54 |
| paulgardiner | Yep, that's fine. | 17:11.07 |
| chrisl | tor8: okay, yes I see. It seems my local jbig2dec repo is borked - it claims to be up to date, but the last commit is from ~6 months ago. A fresh clone is correct - sorry about that. | 17:13.43 |
| mvrhel_laptop | bbiaw | 17:14.27 |
| tor8 | chrisl: great! I was worried the scripts were broken... | 17:14.34 |
| chrisl | tor8: no definitely my repo | 17:15.29 |
| Robin_Watts | tor8: At some point, either you or paulgardiner needs to look over the reflow branch. | 17:15.31 |
| paulgardiner | I'm off out tonight, and need to stop soon, but I could take a look tomorrow | 17:16.31 |
| Robin_Watts | paulgardiner: I was imagining that tor8 would like to look himself, but the more eyes the better. | 17:17.09 |
| paulgardiner | Yeah, both having a look sounds good. | 17:18.11 |
| tor8 | Robin_Watts: I will take a look tomorrow as well. I'd like to get some rudimentary BiDi/RTL stuff in there and that should be base off your new datastructures. | 17:18.27 |
| marcosw | ray_laptop: ping | 17:35.40 |
| kens | OK goodnight everyone | 17:39.35 |
| ray_laptop | marcosw: sorry -- was on the phone | 17:40.33 |
| marcosw | I may have figured it out on my own. GIve me a sec... | 17:41.27 |
| | ray_laptop: I was trying to duplicate a customer problem and build without the pdfwrite device, turns out you also have to remove the ps2write device (I understand why this is but it's still kind of odd, explicitly removing a device and still having it available). | 17:49.45 |
| ray_laptop | marcosw: while the files get included, I don't think the pdfwrite device should be on the devices list -- Note that you have to do a 'clean' before rebuilding sometimes to get rid of devices since the .dev files will still be found by genconf | 17:54.19 |
| | I tripped over that because I still had the 'pswrite' device on the list, but then the objects weren't included so I got an 'unresolved' link error | 17:55.16 |
| vtorri | tor8, ping | 18:02.56 |
| Robin_Watts | tor8: better version of that timing commit: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=a291ddac0d6b7923cdcbd6644bdd89dd315b6921 | 18:04.51 |
| | vtorri: hi. | 18:04.55 |
| vtorri | Robin_Watts, hey | 18:05.00 |
| Robin_Watts | You may have missed tor8 for the night. can I help? | 18:05.08 |
| vtorri | Robin_Watts, i wanted to mention a very minor warning to fix in fitz | 18:05.35 |
| | Robin_Watts, ./src/modules/pdf/mupdf-1.2/fitz/fitz.h:3068:1: warning: function declaration isn't a prototype | 18:05.55 |
| | just add void | 18:06.04 |
| Robin_Watts | tor8: also http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=c92a51cb111f997c94ec48e20cce90ca27073b55 | 18:07.08 |
| | vtorri: What function declaration is that? | 18:07.42 |
| | int fz_javascript_supported ? | 18:07.58 |
| vtorri | yes | 18:08.09 |
| | it's the only function with no parameter which does not have void | 18:08.48 |
| Robin_Watts | vtorri, tor8: And so: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=a621800cec7f46c3d3fe34ce7347257110935ea3 | 18:09.16 |
| | vtorri: Thanks. | 18:09.21 |
| vtorri | Robin_Watts, check the definition of the function too | 18:09.41 |
| Robin_Watts | vtorri, tor8:http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=afd5d5dd443a9f37aff1e48f96136ab2e11213bb | 18:11.17 |
| | vtorri, tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=afd5d5dd443a9f37aff1e48f96136ab2e11213bb | 18:11.30 |
| | Thanks. | 18:11.32 |
| vtorri | you're welcome | 18:11.39 |
| Robin_Watts | That'll hit the main repo as soon as tor8 OK's it. | 18:12.00 |
| vtorri | ok | 18:12.09 |
| | i have a bunch of gcc warning flags :) | 18:12.36 |
| ray_laptop | aren't we really at a point where we should get away from the 'gatekeeper' model for mupdf git -- we now have cluster regression for mupdf available and working without a gatekeeper on Ghostscript has worked fine for years | 18:14.32 |
| | plus it would keep the mupdf commits from getting batched up and disperse the commit regression runs and the emails for the commits and the regressions | 18:15.31 |
| Robin_Watts | ray_laptop: No. It's not a 'gatekeeper' model, it's a 'code review' one. | 18:16.37 |
| | and I'd argue that code reviews would help on gs too. | 18:16.56 |
| ray_laptop | still it batches thing up | 18:16.58 |
| Robin_Watts | ray_laptop: Right, but a mupdf commit takes 5 minutes to run through on the cluster, and the user jobs take priority. | 18:17.26 |
| ray_laptop | Robin_Watts: on gs we all get commits and look over the changes after the fact. It's more efficient | 18:17.32 |
| Robin_Watts | ray_laptop: On gs we get commits, followed by commits to fix the breakages. | 18:17.57 |
| ray_laptop | If people do a private regression run, breakages shouldn't happen. I thought that was our modus operandi | 18:19.00 |
| Robin_Watts | on mupdf we get code reviews, so the code tends to be in nicer shape when it goes in. How many times have you ever shown your code to someone only for them to look at it and say "wouldn't it be a bit nicer if you'd done it like that?" | 18:19.04 |
| ray_laptop | never on a mupdf commit ;-) | 18:19.34 |
| Robin_Watts | (maybe your code is perfect - I know that mine benefits from someone else casting their eyes over it) | 18:19.38 |
| | (oops missed the :) there) | 18:19.47 |
| | Code reviews work well for mupdf. I'd personally like to see us try them on gs, but I raised that idea years ago, and got smacked down, so so be it. | 18:20.44 |
| ray_laptop | I sometimes ask a particular person (someone that I know is familiar with an area) as I am working on a change, but I'm not sure that we could have just one person review all gs commits | 18:21.17 |
| Robin_Watts | ray_laptop: Right, and we're not in that position for mupdf. | 18:21.31 |
| henrys | yeah I really don't think the gs review after commit model works at all. Everyone ignores the commits AFAICT, there is no review. | 18:21.35 |
| Robin_Watts | The rule is that every commit that hits the mupdf golden git repo should have been looked at by at least 2 developers (the original author, and one other) | 18:22.11 |
| vtorri | Robin_Watts, i guess that you don't care about unused parameters, right ? | 18:22.18 |
| ray_laptop | we had tried forcing 'ownership' of certain aspects to individuals, but that finally fell apart when people needed to touch too many areas to | 18:22.21 |
| henrys | ah some chat on ubuntu irc | 18:22.57 |
| ray_laptop | Robin_Watts: do preliminary commits get bounced often, then ? | 18:23.11 |
| Robin_Watts | For some areas of code there will inevitably be cases where only one person really understands the code (say, in gs, clist changes may not make much change to anyeone other than ray), but even dumb users can spot silly typos etc. | 18:23.52 |
| | ray_laptop: It's extremely typical for commits to be tweaked slightly, yes. | 18:24.10 |
| | Either for reasons of style, or for silly typos, or for people spotting corner cases. | 18:24.30 |
| | Also, it serves to ensure that all the knowledge about particular areas isn't completely embedded in just one developers head. | 18:24.49 |
| | henrys: Meetings are going on all day there. Ours isn't schedules for 2 hours, right? | 18:25.18 |
| | Currently it's the calculator app meeting. | 18:25.29 |
| ray_laptop | well, we have LOTS of spelling errors in comments, but for most of those, it was the code 'owner' that made the errors and that person would accept no critique | 18:25.44 |
| | is all the discussion on #ubuntu, or are there separate channels ? | 18:26.34 |
| henrys | Robin_Watts: well I watch for a while earlier and it was completely dead - now lots of activity, I know it isn't relevent to us | 18:27.15 |
| Robin_Watts | ray_laptop: I'm currently lurking on #ubuntu-desktop, #ubuntu-touch and #ubuntu-touch-meeting | 18:28.03 |
| henrys | ray_laptop: Robin_Watts sent out email about tuning in. | 18:28.11 |
| Robin_Watts | The latter is where the meeting is due to take place. | 18:28.21 |
| | I worry that if we all turn up, we'll drown out the devs, but... :) | 18:28.40 |
| vtorri | i have a problem with the jbig2dec included in mupdf | 18:30.33 |
| | config_types.h is requires but i can't find it | 18:30.47 |
| | is it generated in a Makefile ? | 18:31.00 |
| Robin_Watts | vtorri: this is the jbig2dec you get from git submodules? | 18:31.38 |
| | and on what platform are you building? | 18:31.47 |
| vtorri | from the mupdf1.2 source | 18:31.48 |
| | win32 (msys/mingw-w64) | 18:32.06 |
| | win64 actually | 18:32.22 |
| Robin_Watts | So you're building using MSVC? | 18:32.33 |
| vtorri | no | 18:32.37 |
| | msys/mingw-w64 | 18:32.41 |
| Robin_Watts | OK, so jbig2dec/os_types.h has a rats nest of #ifdefs at the top. | 18:33.14 |
| | If you've defined HAVE_CONFIG_H then it (reasonably enough I feel) will look for config_types.h | 18:33.55 |
| vtorri | hoo, indeed | 18:34.03 |
| | it is defined | 18:34.11 |
| Robin_Watts | So... don't define it, or provide a config_types.h :) | 18:34.29 |
| vtorri | what should i contain ? | 18:34.50 |
| | it* | 18:34.53 |
| Robin_Watts | essentially we use it for definitions of {u,}int{8,16,32}_t | 18:35.13 |
| vtorri | hmm | 18:35.22 |
| Robin_Watts | if you don't define it, and don't define any of the other things, you'll end up using the definitions in that file which are fairly sane. | 18:35.52 |
| vtorri | ok, the c99 types are already defined by mingw-w64 | 18:36.36 |
| | so an empty file is enough | 18:36.45 |
| | Robin_Watts, you won't fix the warning "unused parameter", right ? | 18:39.19 |
| Robin_Watts | vtorri: I think most of our 'unused parameter' warnings are because functions are defined to take a particular set of params so we can take function pointers to them. | 18:40.15 |
| | i.e. they are only unused in certain implementations. | 18:40.39 |
| vtorri | ok | 18:40.54 |
| Robin_Watts | so there is no 'correct' way to fix the code. We can't just remove the unused params. | 18:41.01 |
| vtorri | and shadow variable warnings ? | 18:41.08 |
| Robin_Watts | Those we should fix. | 18:41.59 |
| vtorri | pass -Wshadow, then :) | 18:42.09 |
| | and you'll see that there're a lot of them | 18:42.32 |
| | well, lot is maybe exagerated | 18:43.07 |
| | there are also some uninitialized variables | 18:43.55 |
| Robin_Watts | vtorri: Those are spurious. | 18:44.07 |
| | gcc's warning that a variable may be used when uninitialised are frequently wrong. | 18:44.46 |
| | The warning really means "I'm too thick to convince myself that this is safe, so I'll complain" | 18:45.05 |
| vtorri | int pdf_js_supported(); in mupdf-internal.h | 18:45.08 |
| | (missing void too) | 18:45.16 |
| | check definition too | 18:45.45 |
| Robin_Watts | vtorri: tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=e219f89eab0e937b14ac2d8838296078f5fa2b35 | 18:47.11 |
| | Thanks. | 18:47.14 |
| | henrys: This CLA in bugzilla thing. | 18:47.33 |
| tor8 | Robin_Watts: LGTM | 18:47.33 |
| Robin_Watts | tor8: 2 others there too... | 18:47.55 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=a291ddac0d6b7923cdcbd6644bdd89dd315b6921 | 18:48.02 |
| | (better version that works without using clock) | 18:48.09 |
| | and http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=c92a51cb111f997c94ec48e20cce90ca27073b55 | 18:48.20 |
| | henrys: When attaching a patch, people have to click the 'patch' checkbox. | 18:49.06 |
| | Can I just change the template to say "By uploading a patch you accept the Artifex CLA" with a link to the CLA ? | 18:49.49 |
| | Or do you want acceptance to be a separate step? | 18:50.00 |
| tor8 | fitz/util_time.c has gettimeofday for windows | 18:50.16 |
| Robin_Watts | tor8: Using GetTickCount is faster. | 18:50.45 |
| tor8 | Robin_Watts: okay. then the 3 oldest on robin/master LGTM | 18:51.04 |
| Robin_Watts | tor8: Thanks. | 18:51.10 |
| vtorri | GetTickCount has a precision of E-2s | 18:51.32 |
| | 1E-2s | 18:51.42 |
| Robin_Watts | It's a millisecond counter. And I want a millisecond counter :) | 18:52.01 |
| vtorri | it's not millisecond | 18:52.23 |
| | it's above | 18:52.30 |
| | (contrary to what msdn says) | 18:52.43 |
| Robin_Watts | vtorri: It returns values in milliseconds. It may not be ACCURATE to milliseconds (i.e. there is jitter) | 18:53.13 |
| | For what I need, it's perfect. | 18:53.21 |
| vtorri | ok | 18:53.24 |
| | otherwise, you have high frequency counters | 18:53.49 |
| Robin_Watts | indeed. I have used them before for profiling. | 18:54.02 |
| | This is for some debug code to give a rough idea of the contention of using locks. | 18:54.27 |
| | It's impossible to do that accurately without system support, so a small amount of jitter isn't going to make a large difference. | 18:54.58 |
| vtorri | ok | 18:55.13 |
| henrys | Robin_Watts:A signed Artifex CLA is prerequisite to patch acceptance. Where Aritfex CLA is a link? | 19:20.46 |
| Robin_Watts | yes. | 19:29.16 |
| | henrys: You actually want a signed CLA? | 19:30.04 |
| | or you just want them to have accepted the CLA as part of the patch upload process? | 19:30.21 |
| | The simplest thing for me to do is to change the wording on the attachment thing and have a link to the CLA. | 19:31.07 |
| henrys | Robin_Watts: after the experience we've had yes. | 19:31.16 |
| Robin_Watts | A more complex thing might have the submit button go to another page that shows the CLA and says "only continue to upload your patch if you agree with this" | 19:31.53 |
| | but it sounds like neither of those are enough for what you want. | 19:32.08 |
| henrys | Robin_Watts: your solution doesn't need to enforce the policy, we'll do that, the notice just saves us a step | 19:33.19 |
| Robin_Watts | ok. | 19:33.35 |
| ray_work | Wow! my fix for the 09-03.PS psdcmyk clist bug 693718 showed up a very significant progression on comparefiles/PP0001G0.pdf.psdcmyk.300.1 -- Quite unexpected. We used to be missing a LOT of text but other stuff, too | 19:42.31 |
| Robin_Watts | ray_work: Nice. | 19:44.35 |
| henrys | ray_work:good news, do you think someone should look at the psdcmyk output? | 19:45.50 |
| ray_work | that's a lot of eyeball time. Maybe automate flattening it to RGB (like bmpcmp does) and compare to ppmraw output ? | 19:46.56 |
| | actually, bmpcmp flattens to cmyk, iirc. But RGB would be enough to equal or exceed eyeball review | 19:47.48 |
| Robin_Watts | bmpcmp compares in cmyk and just converts to rgb for diff. | 19:49.22 |
| ray_work | Robin_Watts: right, but comparing ppmraw RGB to (psdcmyk flattened to RGB) should be sufficient, right ? | 19:51.42 |
| Robin_Watts | yes, just saying that bmpcmp won't do it as is. | 19:52.03 |
| ray_work | Robin_Watts: I realize that. | 19:53.06 |
| Robin_Watts | but yes, it's a good idea. | 19:53.18 |
| ray_work | what the heck. my gitpush localcluster regression thinks it has 17K objects to write, but it is only 4 objects from origin/master that I last did a localcluster test from | 20:01.45 |
| | Robin_Watts: meeting starting in #ubuntu-touch-meeting (it looks like) | 20:04.04 |
| | well, maybe :-/ | 20:04.48 |
| Robin_Watts | henrys: http://bugs.ghostscript.com/attachment.cgi?bugid=693692&action=enter | 20:07.07 |
| | ray_work: That's for the RSS reader, I think. | 20:07.44 |
| ray_work | Robin_Watts: I think so. But the #endmeeting already happened for that one :-) | 20:08.30 |
| | Robin_Watts: for the CLA, it's http://bugs.ghostscript.com/attachment.cgi?id=9346 | 20:10.05 |
| Robin_Watts | ray_work: that's what I link to at the above link. | 20:10.50 |
| henrys | Robin_Watts:looks good to me. | 20:12.53 |
| | thanks | 20:12.56 |
| Robin_Watts | np. | 20:13.01 |
| tkamppeter | Robin_Watts, now there should be our meeting at #ubuntu-touch-meeting. | 20:33.25 |
| Robin_Watts | tkamppeter: Yeah, I'm there, as are others. | 20:33.39 |
| henrys | well that was interesting... | 21:04.13 |
| Robin_Watts | I think we've got in at the right point of the project (i.e. before anything has been started) | 21:05.16 |
| henrys | yes, I think there are some issues, I think they are stuck with the cairo library and poppler for apps .. so that's a hurdle | 21:06.15 |
| kens | Just got in, waS THE MEETING USEFUL ? | 21:06.30 |
| Robin_Watts | Whatever apps use to output pdf is up to them. | 21:07.17 |
| kens | OK | 21:07.36 |
| Robin_Watts | Whether they can overcome the impetus of just sticking with what they know is going to be the question. | 21:10.36 |
| kens | Hmm I suspect the answer to that one will be 'no' | 21:10.52 |
| tor8 | usually seems to be the case... one would hope that being a new platform the inertia to overcome may be less... | 21:11.33 |
| henrys | they all use cairo as a graphics library right? and that library can produce pdf? poppler and cairo are under the same group and presumably that is desirable - eating your own dog food. We have discussed getting MuPDF a real graphics graphics library API that apps could use. Maybe we should study that more. | 21:12.35 |
| Robin_Watts | henrys: If we had pdfout, then the device interface *is* that interface. | 21:15.51 |
| henrys | Robin_Watts:I guess I'm not following the - the app writers need cairo to draw pictures on the screen - let's say the paint tool app - it draws lines, beliers, whatever with cairo. How do I replace that with mupdf. - where is the api call to draw a curve? | 21:20.09 |
| Robin_Watts | henrys: fz_create_pixmap to make something to draw on. | 21:20.51 |
| | dev = fz_new_draw_device(pixmap) | 21:21.12 |
| | Then you call any of our drawing functions with that device. | 21:21.27 |
| | You can build paths and call fz_fill_path(dev, path); etc. | 21:21.58 |
| | Or you can call fz_fill_text etc. | 21:22.51 |
| | Essentially the interpreter reads through pdf content streams breaking them down to such calls. | 21:23.19 |
| | The draw device knows how to render such calls. | 21:23.39 |
| | And the display list device knows how to record such calls such that it can play them back to another device (such as the draw device) later. | 21:24.09 |
| | If we had a pdfout device (which we kinda do, but it's unfinished), then people could render to PDF just by calling the device interface. | 21:24.39 |
| henrys | but I'm an app programmer how would I possibly figure all that out? What we need is to package it as a documented library - see http://cairographics.org/manual/. | 21:26.34 |
| Robin_Watts | henrys: Well, step 1 would be to finish pdfout :) | 21:28.55 |
| henrys | agreed | 21:29.53 |
| kens | OK I have to go again, night all | 21:31.18 |
| tkamppeter | Robin_Watts, do you have a file sample-for-large-pxlcolor-output.pdf in your test repo? It is dead-slow with GS and really fast with both MuPDF and Poppler. | 21:46.08 |
| Robin_Watts | tkamppeter: Not that I can see. | 21:47.20 |
| henrys | tkamppeter: to what device are you rendering in gs? pxlcolor has a different performance profile than raster devices. | 21:49.56 |
| tkamppeter | Robin_Watts, see your mail. | 21:50.57 |
| | henrys, I simply displayed the files on the screen, no hi-res print output. | 21:54.01 |
| | Simply | 21:54.46 |
| | gs sample-for-large-pxlcolor-output.pdf | 21:55.01 |
| | and | 21:55.03 |
| | mupdf sample-for-large-pxlcolor-output.pdf | 21:55.08 |
| | on Linux. I also opened it with MuPDF on the Nexus 7 (Android) and it renders quickly there, too. | 21:55.47 |
| henrys | there are some problems with the default x11 device - we don't have a user base for it. If you can reproduce the problem going to a file it would be nice to have a bug report. | 21:55.53 |
| tkamppeter | henrys, OK, so PDF screen display on Linux with GS should better be avoided. | 21:57.02 |
| henrys | tkamppeter: that's my view of it. I sort of see it as a development tool. | 21:58.14 |
| | in the debugger you can see the graphics drawn as you step through the code, that's what it is good for. | 21:58.55 |
| Robin_Watts | henrys: So it's utterly useless on windows then. | 21:59.37 |
| | tkamppeter: 16 page document. I wonder if just one page is slow. | 22:00.28 |
| henrys | Robin_Watts:it is an X11 device. | 22:02.46 |
| Robin_Watts | So the windows display device doesn't have the same problem? | 22:02.46 |
| tkamppeter | Robin_Watts, the article text is slow under X11, the pictures are no problem. | 22:03.06 |
| Robin_Watts | is the default device x11alpha? | 22:04.07 |
| tkamppeter | Robin_Watts, yes, if I switch to X11, rendering is fast again. | 22:05.04 |
| Robin_Watts | I understand. | 22:05.22 |
| tkamppeter | Robin_Watts, so no good sample to show how much faster MuPDF is. | 22:05.59 |
| Robin_Watts | tkamppeter: Oh, and mupdf has cunning stuff in to support multi-threaded rendering etc. dunno if that's useful for you. | 22:42.28 |
| ray_work | the fitz rendering is (mostly) designed to support AA rendering everywhere. In fact turning it off for some devices (that have low depth) was only added after a few years. | 22:50.08 |
| | OTOH, gs has AA (TextAlphaBits and GraphicsAlphaBits) sort of kloodged in | 22:51.01 |
| | since gs was/is mostly printer focused and there aren't low res contone printers | 22:52.01 |
| | Robin_Watts: Does mupdf to x11 only update the page when the rendering of the page is complete ? | 22:53.17 |
| ray_laptop | has anyone else seen this error? | 23:48.49 |
| | misc errors: Use of uninitialized value $mujstest in concatenation (.) or string at run.pl line 1449. (repeated MANY times) | 23:48.50 |
| | marcosw: the question above is probably for you | 23:49.48 |
| marcosw | ray_laptop: oops, probably my tinkering with the cluster code earlier today. | 23:50.25 |
| ray_laptop | marcosw: np. That's what I assumed | 23:50.43 |
| | marcosw: so we need a regression test to allow you to test your changes to the regression scripts :-) | 23:51.14 |
| | and then another script to test that, and ... | 23:51.31 |
| marcosw | ray_laptop: I've lobbied for a test cluster for some time :-) | 23:52.02 |
| | ray_laptop: should be sorted. | 23:55.40 |
| | ray_laptop: just to confirm, these errors only happened during bmpcmp runs, correct? | 23:56.32 |
| | Forward 1 day (to 2013/03/22)>>> | |
IRC Logs