| | <<<Back 1 day (to 2013/05/16) | 2013/05/17 |
| vtorri_ | tor8, hey | 08:50.16 |
| tor8 | hi | 08:51.04 |
| ghostbot | bonjour | 08:51.04 |
| vtorri_ | tor8, do you have some time for explaining me how to use display list, please ? | 08:51.28 |
| tor8 | vtorri_: there are many examples of display list use in the code. what do you need help to understand? | 08:55.13 |
| vtorri_ | i write a library that display a pdf | 08:56.27 |
| | that library will be used in a program | 08:56.39 |
| | do I have to create a display list before the rendering of each page, then freee it after the rendering is finished ? | 08:57.15 |
| | or do I create it once at the beginning and free it when the program finishes ? | 08:57.40 |
| tor8 | using a display list is optional | 08:58.09 |
| | the display list is a recording of the page drawing commands | 08:58.47 |
| vtorri_ | like ? | 08:59.28 |
| tor8 | you may get increased performance by using the display list to record the drawing commands for repeated play back | 08:59.35 |
| | if you only draw the page once, there is no benefit to using a display list | 08:59.45 |
| | consider the case when you are zooming around on a page | 09:00.19 |
| | then you are redrawing the page many times after each other. using a display list there makes sense. | 09:00.39 |
| | without the display list, you have to interpret the PDF page multiple times | 09:00.55 |
| | with the display list, it's interpreted once and then quickly played back each time you draw the page | 09:01.21 |
| vtorri_ | so, if the user uses zoom in / zoom out on the page, it can speed up stuff | 09:01.30 |
| | and rotation too ? | 09:01.35 |
| tor8 | the drawback is that a display list uses lots of memory | 09:01.39 |
| vtorri_ | hmmm | 09:01.47 |
| | good to know | 09:01.52 |
| | especially for embedded | 09:01.59 |
| | so | 09:02.16 |
| | zooming or rotating : display list | 09:02.26 |
| tor8 | if you have enough memory, I would recommend caching the display list for the current page so that zooming and rotating can be sped up | 09:02.27 |
| | but don't hold on to them for a long time. re-interpreting the page is not *that* much more expensive. | 09:02.47 |
| | so: keep one display list for the current page, use that to draw and redraw when zooming / rotating. | 09:03.09 |
| | when you need to draw another page, discard the display list and make a new one for the new page | 09:03.26 |
| vtorri_ | new page : i free it and create a new one | 09:03.29 |
| tor8 | yes. | 09:03.37 |
| vtorri_ | ok | 09:03.37 |
| | i should add an option to disable display lit | 09:03.59 |
| tor8 | having a display list is also useful for if you want to extract text for copying or searching | 09:04.02 |
| vtorri_ | haaa | 09:04.09 |
| | yes, i'll need that | 09:04.19 |
| tor8 | since that also counts as "drawing" the page | 09:04.19 |
| | I have some plans for a "multiplexing" device that lets you run a page through multiple devices simultaneously | 09:04.42 |
| | but I haven't got around to it yet | 09:04.47 |
| vtorri_ | when you say "caching it", you mean store it in a variable, right ? | 09:04.52 |
| | there is no specific stuff to do | 09:05.00 |
| tor8 | yes. just keep it around until you change page. | 09:05.10 |
| vtorri_ | great | 09:05.15 |
| | i understand more | 09:05.19 |
| | thank you | 09:05.21 |
| tor8 | np | 09:05.30 |
| vtorri_ | what is the interest of fz_var() ? | 10:00.34 |
| Robin_Watts | vtorri_: It's to do with fz_try/fz_always/fz_catch | 10:04.42 |
| vtorri_ | ok, thanks | 10:04.57 |
| | on the other hand, in 1.2, that function seems to do nothing | 10:05.12 |
| Robin_Watts | If a variable is set in the fz_try section, and then may be used after that section in the case of something throwing an exception, you must fz_var it first. | 10:06.03 |
| | fz_try/fz_catch etc are implemented using setjmp/longjmp/ | 10:06.20 |
| | And the problem is that if you longjmp, any local variables that have been set since the setjmp can lose their values. | 10:06.49 |
| | fz_var is a cunning trick that stops that happening. | 10:07.13 |
| vtorri_ | ok | 11:06.26 |
| | is it a problem if i don't use at all tz_try/always/catch ? | 11:34.23 |
| tor8 | vtorri_: if you don't mind your app doing exit() on errors... | 11:37.49 |
| vtorri_ | check all the pointers | 11:38.06 |
| | +I | 11:38.10 |
| | it's not sufficient ? | 11:38.20 |
| tor8 | many many things can cause errors. such as broken PDF files. | 11:38.43 |
| vtorri_ | ho | 11:38.49 |
| | ok | 11:38.53 |
| Robin_Watts | vtorri_: When coding in C, your options are: 1) ignore errors, 2) return an error code from every sodding function, 3) roll your own exception handling. | 11:39.34 |
| | Initially mupdf did 1. | 11:39.44 |
| | but when we decided that wasn't enough, we didn't want to rewrite it all to do 2. | 11:39.58 |
| | so we did 3. | 11:40.03 |
| | and on the whole it's worked well - the flow of the program is maintained, the code is nicely readable, and we can cope efficiently with errors/exceptions etc. | 11:40.36 |
| | fz_var is one of two major wrinkles. | 11:41.10 |
| | the other being to remember never to return from inside an fz_try. | 11:41.21 |
| tor8 | Robin_Watts: it does put a burden on users though... it would be fairly trivial to create a naive wrapper for the top level functions called that wrap the try/catch and return error codes. something we'd need if we're going to create a more one-to-one language binding for java for instance | 11:43.23 |
| Robin_Watts | tor8: I'd claim that the java bindings would convert from our exceptions to java exceptions. | 11:43.57 |
| | likewise C++ | 11:44.03 |
| | so the exceptions should be kept external to the API. | 11:44.18 |
| tor8 | that'd work too. | 11:44.18 |
| | it would make it harder to use automatic code generation tools to create language bindings though | 11:45.04 |
| Robin_Watts | yes. | 11:45.35 |
| | tor8: though we could automatically generate, and then hand tune. | 11:45.54 |
| tor8 | or just write our own automatic code generation | 11:46.33 |
| | SWIG is probably a monster these days. it was bad enough 10 years ago... | 11:46.53 |
| | Robin_Watts: don't know if you saw, but there are two patches on tor/master that need some eyeballs | 11:49.50 |
| Robin_Watts | Are they the same as last nights? | 11:50.02 |
| | if so, I pushed them to golden. | 11:50.09 |
| tor8 | Robin_Watts: ah, so you did! thanks. | 11:50.39 |
| Robin_Watts | I wondered for a bit if we should have a "compare colorspaces" call, but having thought about it, I think equality is probably ok. | 11:51.13 |
| tor8 | Robin_Watts: just a question on your git wokflow. those patches have different sha1:s but are rooted on the same parent | 11:51.22 |
| | do you always cherry-pick when you push? | 11:51.34 |
| Robin_Watts | tor8: I pull them into my repo, where I have extra commits. | 11:51.44 |
| | then I rebase them to the right place in the history, then I push | 11:51.55 |
| tor8 | Robin_Watts: right, that explains it! | 11:52.07 |
| Robin_Watts | so, it has the unfortunate effect of changing the SHAs. Is that a problem? | 11:52.09 |
| tor8 | no, not at all | 11:52.15 |
| | just makes me wonder if you did any edits | 11:52.23 |
| Robin_Watts | fab. | 11:52.26 |
| paulgardiner | robin_watts: I think if you used fetch they'd come in at the right location and you wouldn't need to rebase them, | 12:05.18 |
| Robin_Watts | paulgardiner: If I pull --rebased them, then they would come at the right point. | 12:05.43 |
| | and sometimes I do. | 12:05.52 |
| | with tor's I fetched then cherry picked. | 12:06.00 |
| | then rebased. | 12:06.05 |
| tor8 | I usually cross-push (git push origin sha1:master) | 12:06.52 |
| Robin_Watts | tor8: That's what I do. | 12:07.03 |
| | git push golden master~2:master :) | 12:07.23 |
| tor8 | yeah, but I do it from any branch to any | 12:07.46 |
| | git push origin robin/master:master | 12:08.04 |
| Robin_Watts | tor8: right, but then I'd still have to pull your changes back into my master. | 12:08.11 |
| | Anyway, it's git. There are many ways to do things :) | 12:08.29 |
| paulgardiner | robin_watts: maybe I misunderstood what the issue was. I though you'd pushed some of tor8's commits and they'd changed sha although they were at the same place in history as tor8 created them | 12:08.31 |
| tor8 | and then when it's time to publish, I rebase to origin/master and push -f tor | 12:08.33 |
| | paulgardiner: they were, because he cherry picked on top of his local commits, then rebased them to eariler | 12:08.59 |
| | back to the same parent they originally came from | 12:09.09 |
| | (IIRC) | 12:09.19 |
| paulgardiner | But that would also happen with pull --rebase | 12:09.23 |
| Robin_Watts | No. | 12:09.31 |
| tor8 | pull --rebase would rebase his local commits on top of the existing sha1 from the remote | 12:09.46 |
| Robin_Watts | pull --rebase would take tors commits as is, and rebase my new ones to be after them. | 12:09.51 |
| paulgardiner | Ah | 12:10.09 |
| | right | 12:10.11 |
| | of course it does | 12:10.18 |
| Robin_Watts | often golden has moved on by the time a review has been done. | 12:10.25 |
| | hence pull --rebase from somewhere that's not up to date causes problems. | 12:10.45 |
| | hence I fetch and cherry-pick. | 12:10.54 |
| | gah. my vmware box doesn't have the memory for this valgrind problem :( | 12:16.14 |
| | time to slow peeves to a crawl. | 12:16.21 |
| kens | Hmm, the bbox device seems to be broken for text | 13:11.54 |
| | Well, that's puzzlng. If I go back to the 9.07 release code, it still fails for me, but if I use the released binary, it works.... | 13:22.15 |
| | Ah its OK I just can't read | 13:25.09 |
| tor8 | Robin_Watts: quick fix on tor/master | 13:38.16 |
| Robin_Watts | Gah. Stupid valgrind. | 13:47.03 |
| kens | not a real bug ? | 13:47.40 |
| Robin_Watts | When you do a valgrind check of a block of memory, and it fails, it'd be really nice if it told you what block you checked. | 13:47.51 |
| | or, which set of bytes in the block are undefined. | 13:55.37 |
| | tor8: pushed. | 14:00.33 |
| kens | tor8 Robin_Watts : someone claiming they can't build from current git: | 14:23.08 |
| | http://stackoverflow.com/questions/16609804/compiling-mupdf | 14:23.08 |
| tor8 | kens: that's the fix robin just pushed for me :) | 14:23.42 |
| kens | Ah, OK I'll tell him that. | 14:23.51 |
| Robin_Watts | OMG! Compile Failed! Post to StackOverflow! | 14:24.58 |
| | kens: you might want to point out that if he's working from the git head, he can expect occasional breakages. | 14:25.31 |
| kens | Uh, I already replied.... | 14:25.45 |
| tor8 | notice how all these posts always have reputation scores in the single digits? | 14:25.45 |
| kens | Because they only *ask* questions.... | 14:25.59 |
| | henrys I'll be interested to hear what happens returning gs_no_glyph | 14:27.27 |
| henrys | kens:I suspect another can of worms but it does seems worthwhile to try. | 14:30.00 |
| kens | henrys I suspect it will indeed be more worms, but its an interesting idea | 14:30.21 |
| Robin_Watts | does the mvrhel_laptop summoning dance. | 15:38.13 |
| | Hi mvrhel_laptop. Got time for a word? | 15:55.11 |
| mvrhel_laptop | Hi robin_watts. yes | 15:56.40 |
| Robin_Watts | I've got a fuzzing bug that hits valgrind problems in interpolate_image_icc | 15:57.02 |
| mvrhel_laptop | ok | 15:57.28 |
| Robin_Watts | (actually, it hits them in CachedXForm in lcms2, but it's because interpolate_image_icc is feeding uninitialised data in). | 15:57.29 |
| | and I think I've figured out why. I'd like another pair of eyes to double check me before I spend more time on this. | 15:58.01 |
| mvrhel_laptop | ok. let me bring up gs | 15:58.19 |
| Robin_Watts | In interpolate_image_icc (in gxiscale.c) we're called with a buffer of data at address P of width W. The first thing we do is to call initial_decode. | 15:59.00 |
| | that's returning with stream_r.ptr set to be P + W-1. | 15:59.19 |
| mvrhel_laptop | so you are in image_render_interpolate_icc? | 15:59.43 |
| Robin_Watts | Yes, sorry. | 15:59.52 |
| | My debugging indicates that the stream_r.ptr is set at around line 618 | 16:00.26 |
| | so the code is detecting that we're being called with more than 8bpp, in a non-indexed space. | 16:00.54 |
| mvrhel_laptop | ok | 16:01.28 |
| Robin_Watts | The problem is, I think, that the is_icc case does not allow for reversed = 1 | 16:01.50 |
| mvrhel_laptop | reversed=1 is.... | 16:02.08 |
| Robin_Watts | That the data is flipped on X. | 16:02.19 |
| mvrhel_laptop | having flashbacks of too many options in this part of the code | 16:02.27 |
| Robin_Watts | mmm :) | 16:02.34 |
| mvrhel_laptop | it is very possible that that was overlooked | 16:02.43 |
| | and not tested in our files | 16:02.54 |
| | 16 bit interpolation with flipped in X direction | 16:03.07 |
| | I can see where this is likely headed | 16:03.36 |
| | there is a if (reversed) { | 16:03.56 |
| Robin_Watts | where? | 16:04.13 |
| mvrhel_laptop | line 611 | 16:04.18 |
| Robin_Watts | right, yes, sorry. | 16:04.25 |
| mvrhel_laptop | if (reversed) { | 16:04.26 |
| | pdata += (pss->params.WidthIn - 1) * dpd; | 16:04.27 |
| | dpd = - dpd; | 16:04.29 |
| | } | 16:04.30 |
| Robin_Watts | That makes pdata point at the END of the row rather than the start, and makes dpd be the amount to step backwards between pixels rather than forwards between pixels. | 16:05.04 |
| | but all this is lost when the function exits. | 16:05.11 |
| mvrhel_laptop | right | 16:05.11 |
| Robin_Watts | The calling code has no way of knowing that it's reversed. | 16:05.27 |
| mvrhel_laptop | it should end up decoding it into the buffer reversed though | 16:05.34 |
| | this should have fixed the reversing | 16:05.47 |
| | unless it is getting reversed twice.... | 16:05.59 |
| Robin_Watts | No, cos it reads from the end of the buffer forwards into hyperspace, rather than from the start of the buffer forwards. | 16:06.07 |
| mvrhel_laptop | "it" being.... | 16:06.26 |
| Robin_Watts | (i.e. the data is read in the surrounding code from stream_r.ptr) | 16:06.33 |
| | it being "image_render_interpolate_icc" | 16:07.14 |
| mvrhel_laptop | oh i see | 16:07.21 |
| | the if (is_icc) | 16:07.25 |
| | just sets the pointer | 16:07.30 |
| Robin_Watts | Yes. | 16:07.32 |
| mvrhel_laptop | to the end | 16:07.33 |
| | and then we merrily read beyond that | 16:07.41 |
| | later after we return | 16:07.45 |
| Robin_Watts | All the other 'reversed' cases end up copying the data from psrc -> pdata and reversing it into pdata -> ... | 16:08.01 |
| mvrhel_laptop | we should do the same here if it is reversed | 16:08.12 |
| Robin_Watts | OK, that's what I figured. I'll give that a whirl. Thanks. | 16:08.26 |
| mvrhel_laptop | thanks for tracking that down | 16:08.33 |
| Robin_Watts | no worries. I was worried that the valgrind error was pointing to something I'd broken in lcms2 :) | 16:08.51 |
| mvrhel_laptop | henrys: are you around? | 16:15.09 |
| henrys | I am | 16:15.21 |
| mvrhel_laptop | I see from the support email that customer 801 is doing SIMD halftoning (or trying to) | 16:16.14 |
| | perhaps marcosw should point them to the implementation that I have (it is not post clist but could work just as well) | 16:16.42 |
| | I wonder what they want us to do about that issue as we don't have their code | 16:18.04 |
| henrys | mvrhel_laptop: isn't ray holding their hand through this? | 16:18.40 |
| mvrhel_laptop | I don't think ray has chimed in on this one | 16:19.10 |
| | this is the one entitled Mission some object in output bitmap | 16:19.22 |
| | s/Mission/Missing/ | 16:19.30 |
| | ray has been going over Auto Scaling with them | 16:19.48 |
| | they have been getting their fair share of support.... | 16:20.00 |
| henrys | oh I know he hasn't responded yet to that specific email but generally he is responsible for getting a printer customer up and running so I'm expecting he'll respond soon. I'll text him and tell him to check in at irc | 16:21.15 |
| mvrhel_laptop | henrys: ok. btw, I will send out an email, but I am going to be out Wed-Fri next week. at a camp with my son's 5th grade class. | 16:22.53 |
| ray_laptop | morning, all | 16:23.27 |
| Robin_Watts | morning ray_laptop | 16:23.33 |
| henrys | speak of the devil | 16:23.34 |
| mvrhel_laptop | his ears must of been burning | 16:23.40 |
| ray_laptop | re cust 801, yes, I am holding their hand | 16:23.41 |
| mvrhel_laptop | well you may have to hold both | 16:23.50 |
| | hands | 16:23.59 |
| Robin_Watts | Just hope they don't need to use the bathroom. | 16:24.09 |
| mvrhel_laptop | hehe | 16:24.13 |
| ray_laptop | They sent a .zip file that I haven't' looked at, but it's probably their code | 16:24.16 |
| | I'll look at it today. They are sleeping now and I try and get back to them by 2pm my time, then check during the evening (until I crash) since that allows more than 1 email exchage per day | 16:25.47 |
| | mvrhel_laptop: and I'll mention the SIMD halftoning code that you did | 16:26.26 |
| mvrhel_laptop | it may not be of any use for them. not sure what they are doing exactly | 16:26.45 |
| henrys | alignment maybe? | 16:27.01 |
| mvrhel_laptop | but they may not be aware that it is in there | 16:27.05 |
| ray_laptop | mvrhel_laptop: I don't know either, and their stuff is probably OK | 16:27.12 |
| mvrhel_laptop | alignment with SIMD is certainly critical | 16:27.24 |
| ray_laptop | more likely, they are allocating buffers incorrectly. Rendering threads do have to make sure and use the right allocator | 16:28.15 |
| mvrhel_laptop | right | 16:28.54 |
| ray_laptop | mvrhel_laptop: thanks, I'll mention alignment as well. I assume that your implementation has code to over-allocate and find the aligned point in the buffer ? | 16:29.17 |
| | what alignment is needed ? 64-bit or more ? | 16:30.17 |
| | (easier to ask than look at the code :-) ) | 16:30.45 |
| Robin_Watts | 128bit IIRC. (16 bytes) | 16:31.30 |
| kens | Goodnight all | 16:32.29 |
| Robin_Watts | mvrhel_laptop: How do we know that we have sufficient room to copy the line in there? | 16:34.19 |
| mvrhel_laptop | robin_watts: sorry what are we talking about? | 16:35.14 |
| | interpolation? | 16:35.20 |
| Robin_Watts | sorry. | 16:35.36 |
| | In initial_decode. | 16:35.42 |
| mvrhel_laptop | robin_watts: moved on to winrt land. let me reopen gs.. | 16:36.01 |
| | robin_watts: ok so copy line into where | 16:36.32 |
| Robin_Watts | Ok. let's go back to initial_decode to the place we were looking before | 16:36.54 |
| | Let's follow the non if (is_icc) case. | 16:37.09 |
| mvrhel_laptop | ok at the is_icc | 16:37.11 |
| Robin_Watts | For the non-reversed case, this code makes sense; it reads psrc[j] and writes that to pdata[j] | 16:37.51 |
| | hold on, I've confused myself. Let me unconfuse myself before I waste more of your time, sorry. | 16:38.59 |
| mvrhel_laptop | looks like bdata is allocated on line 459 | 16:39.07 |
| | oh no | 16:39.21 |
| | not allocated set to buffer | 16:39.32 |
| | need to see where buffer in image_render_interpolate is allocated | 16:40.12 |
| Robin_Watts | buffer is the incoming data buffer. | 16:40.22 |
| | from whatever the data source is. | 16:40.31 |
| | I'm all confused by psrc being the output pointer :( | 16:40.52 |
| mvrhel_laptop | oh ok | 16:41.10 |
| | it is the real source color | 16:41.30 |
| | as opposed to the destination color | 16:41.39 |
| | just think that you are simply trying to figure out what the real source value is | 16:41.56 |
| | that is right, it is penum->line | 16:42.37 |
| | with the /* Output */ comment.... | 16:42.51 |
| | allocated on line 334 | 16:43.20 |
| Robin_Watts | mvrhel_laptop: OK. I'm sorted now I think. For a few minutes at least :) | 16:43.57 |
| | Thanks | 16:44.00 |
| mvrhel_laptop | robin_watts: no worries. I will keep gs open... | 16:44.15 |
| henrys | Robin_Watts: I don't think I'm going to give supernatural a super rating ;-) | 18:03.14 |
| Robin_Watts | henrys: really? How much have you watched? | 18:03.27 |
| henrys | 1/2 way through season 1 | 18:03.43 |
| | I did very much like american horror story | 18:04.03 |
| | does it improve? | 18:04.29 |
| Robin_Watts | I'd encourage you to stick the season out. | 18:04.32 |
| henrys | Robin_Watts: yeah I was going to finish it. | 18:04.57 |
| Robin_Watts | IIRC (and it's a long time since I watched S1) the main story arc moves more to the fore towards the end. | 18:05.13 |
| marcosw | Robin_Watts: mail for you from China arrived at my house. I'll bring it to the Miami meeting. | 18:19.41 |
| Robin_Watts | marcosw: Cor. | 18:20.04 |
| | I have no memory of having ordered anything ;) | 18:20.15 |
| | Except the gamestick, and that's not due for a while. | 18:20.29 |
| marcosw | It's a "card" (at least that's what the customs declaration says). The return address is Cloud Imperium, in Santa Monica, California. | 18:20.52 |
| Robin_Watts | marcosw: Oh, pfft. That. Thanks. | 18:21.08 |
| | I backed Star Citizen on kickstarter, and they are sending out silly credit card sized things to prove how sad we all are :) | 18:22.02 |
| ray_laptop | marcosw: at least the return address is in CA. I ordered a cheap watch for my son that he liked ($10 incl. shipping). It arrived broken, I got an RMA from Amazon and they wanted me to return it to the Canary Islands. The cheapest rate I could get was $14. | 18:23.15 |
| | I never order from china unless I'm willing to get ripped off | 18:23.49 |
| marcosw | BTW, any problem if I order something from Lufthansa and have it shipped to your house? On one of my flights last year the footrest wasn't working and so they gave me Euro 125 in vouchers to order from their worldshop.eu site, but they won't ship to the US (not really "worldshop" is it, should be called euro shop). | 18:23.53 |
| Robin_Watts | marcosw: go for it. | 18:24.26 |
| marcosw | Robin_Watts: great, I wonder what the heaviest thing that they sell for Euro 125 is? :-) | 18:24.54 |
| Robin_Watts | ray_laptop: I've ordered from china a couple of times, but only if I'm sure I'm not going to get caught for import duties etc. | 18:25.38 |
| | marcosw: If it's too heavy, I'll just bring it to the next london meeting for you :) | 18:25.56 |
| | Forward 1 day (to 2013/05/18)>>> | |
IRC Logs