| | <<<Back 1 day (to 2012/03/22) | 2012/03/23 |
| henrys | robin_watts_mac:how's nepal? | 03:22.49 |
| robin_watts_mac | Have only seen hotel and had a brief walk around the streets. | 03:49.24 |
| | Helen, as a blonde, is clearly very interesting. | 03:49.40 |
| | I'm entertaining offers in the 40 yak region. | 03:50.19 |
| henrys | that's a lot of yaks | 03:57.12 |
| mvrhel | oh wow | 05:18.06 |
| | hi robin_watts_mac | 05:18.12 |
| | haha | 05:18.22 |
| | so the is catching the eye of everyone | 05:18.37 |
| | s/the/she/ | 05:18.44 |
| | is it around 10am there? | 05:19.14 |
| | think I am done for the night. made some good progress on shading. i have high level colors making it through now but after adding in hl rect fill support for the clip device I buggered something up | 05:20.41 |
| | the clip device is rather interesting the way that it works with the callback procedures. I was not familiar how it all worked until now | 05:22.29 |
| kens | Grr another memory 'gotcha'. To free memory you use gs_free_objtec. Unless of course its a string, in which case you use gs_free_string..... | 09:00.31 |
| paulgardiner | tor8: ping | 13:17.02 |
| tor8 | paulgardiner: heya | 13:17.12 |
| paulgardiner | Do you have a moment to talk about forms? | 13:17.51 |
| tor8 | talk away, I'm messing with updating all the various app icon files so not too busy :) | 13:20.44 |
| paulgardiner | I've made a small step forward in that I have the buttons of calc.pdf going in and out in response to mouse clicks, but I've realised there's goint to be a problem when trying to store state long term. I think the idea of storing info in the pdf dictionaries might have been flawed. Typically we only have one page loaded at a time and destroying the page will throw away the state AFAIKS. I... | 13:25.41 |
| | ...can think fo ways around it, but I just wanted to chack I hadn't misunderstood something. | 13:25.42 |
| tor8 | the underlying pdf objects for a page stay around longer than the "pdf_page" object | 13:26.42 |
| | the dictionaries etc are all cached in the pdf_document xref_entry array | 13:27.01 |
| | they may (not sure if it's implemented or not) be evicted in low memory conditions, but it would be trivial to add a flag to say "dirty, user has updated this object, don't throw it away" | 13:27.39 |
| | the pdf_page struct is mainly for keeping the unpacked and joined page content buffer for parsing | 13:28.34 |
| | and also a convenient place to hook in the annots and links | 13:28.47 |
| paulgardiner | Oh ok. So it should work after all. I am struggling a bit to understand ownership of objects. I see the odd place that reference counting is used, but it looks as though in lots of places addrefing one object holds others in. | 13:30.30 |
| tor8 | we use reference counting in a number of places. the basic rules are: if you obtain on object from a function with "new", "load", "open", "find" or "keep" in the name, it's yours and you have to "drop" it | 13:31.32 |
| | if not, it doesn't belong to you and you must not keep it around longer than the scope of the current function | 13:31.53 |
| | if you do want to keep it (like squirreling it away in a struct) you must first "keep" it | 13:32.13 |
| | so fz_dict_gets does *not* give you ownership, it just lets you peek at the object temporarily | 13:33.10 |
| | (or we'd be reference counting like madly everywhere) | 13:33.29 |
| paulgardiner | annot refers to ->obj and ->ap, but only ->obj is kept. | 13:34.03 |
| | Yes, I was impressed how you get away with very little twiddling of reference counts. | 13:35.04 |
| tor8 | that's because ->ap was obtained from pdf_load_xobject ("load" in the name) but ->obj was obtained by pdf_array_get (no magic word in the name) | 13:35.28 |
| paulgardiner | Oh yeah. I see it now. | 13:36.46 |
| tor8 | this is one reason I'm trying to be very strict with function naming, so we can rely on the names to tell us these things | 13:37.39 |
| paulgardiner | n on the other hand is just temporary and you save a lot of messing about addrefing and freeing. Nice. | 13:37.43 |
| tor8 | quite | 13:37.53 |
| | actually, scrap what I said about evicting in low-memory conditions :) | 13:38.30 |
| | the objects are kept around indefinitely. many many years ago we did flush the object cache occasionally, the memory of that still lingers. | 13:39.09 |
| paulgardiner | I think I see what was confusing me earlier. My first attempts at getting buttons to react didn't work and looked like pdf_load_page was throwing away info, but that was because I'd denoted the change in appearance by altering annot->ap which of course gets reloaded by pdf_load_page | 13:41.43 |
| tor8 | annot->ap is a pdf_xobject, those things get loaded and cached in the fz_store, indexed by the pdf object number | 13:46.46 |
| | feel free to change how the pdf_annot struct works if that makes it easier for you | 13:47.31 |
| | the main reason for being of the pdf_xobject is to wrap the fz_buffer which contains the content stream for interpretation, along with the matrix and other flags | 13:48.05 |
| paulgardiner | Right. But if I just change which xobject annot->ap points at, pdf_load_page will set it back to what it was originally | 13:48.18 |
| tor8 | yeah, you'll want to change the xobject itself (or the pdf_obj dictionary that points out which one to load) | 13:48.53 |
| | I'm guessing we'll want a different xobject for each button state | 13:49.17 |
| | could you make the annot->ap into an array, one entry for each state? | 13:49.42 |
| | we could make the pdf_annots stick around longer than the other things in the pdf_page | 13:50.03 |
| | the only thing heavyweight in the pdf_page is the fz_buffer with the content stream, the rest of it could conceivably stay around as long as the document does | 13:50.42 |
| | (like we do with xps, where the xps_page struct is permanent, but the actual page data gets loaded in and out instead) | 13:51.11 |
| paulgardiner | There seems to be two classes of change: transitory and long-term. For the visual changes due to the mouse button being down, there's no existing place to store the state, but then I guess we don't want to store it longer than the page is around. Long-term stuff like the checked state of a checkbox needs to stay around, but there is a dictionary entry for it's curent state, so I can just... | 13:56.09 |
| | ...update that | 13:56.11 |
| tor8 | I think it'd be fine to do the state update by (a) changing the annot->ap_state field (or what you call it) and (b) pushing back the same change into the pdf object | 13:57.18 |
| | should be fine for both transient and long term stuff | 13:57.29 |
| | doing (b) will keep the state if the page gets unloaded and then loaded back in | 13:58.09 |
| paulgardiner | Yeah... doing the (b) part only for the long-term changes. | 13:58.09 |
| | At the moment, I have an fz_run_display_list call on every appearance change. Do you think I can get away with that for now? I guess at some stage we'll want to make the update more efficient. | 14:02.11 |
| tor8 | paulgardiner: do you run the display lists for the entire page, or just for the annot that changed? | 14:04.09 |
| | I was hoping to have something with fz_pixmaps in layers that get recomposed to the output when things change, so only the annot that changed needs to be redrawn. but for a prototype I don't really care :) | 14:05.34 |
| paulgardiner | Hmmm. Was going to answer that, but the honest answer is I don't know. Hang on. I just want to see what happens if I leave out that call. | 14:05.44 |
| tor8 | all fz_pixmaps have an alpha channel | 14:05.51 |
| | (to answer an earlier question you asked a few days/weeks ago) | 14:07.25 |
| paulgardiner | Ok. So no efficiency gain to drawing the updated annotations over the top of everything else, rather than drawing to a separate pixmap and composing. | 14:09.20 |
| tor8 | not really, making a copy to draw on top of or recomposing is about the same I think | 14:10.47 |
| | memory bandwidth, and all that | 14:11.01 |
| paulgardiner | One way starts with a direct blit copy, whereas the other ends with a compose. The blit might be a little faster than the compose, maybe. | 14:11.53 |
| | Would the composed version looked identical I thought there was some sort of problem with composing antialiased stuff when it's drawn with a transparent background. | 14:13.13 |
| | s/looked identical/look identical?/ | 14:13.31 |
| tor8 | that would depend on the blending mode ;) in the normal case, internally we'd be do the same math | 14:14.07 |
| paulgardiner | Ah yes. That was another thing I was going to ask. Would it be the app that would be allocating the two bitmaps and making sure they were composed? I'm thinking that it might have to be, because the app determines the proportion of the document that is rendered (what subarea is visible). | 14:15.49 |
| tor8 | yeah, I would assume so | 14:16.22 |
| | but I don't think we need to worry too much about that yet, redrawing the page for each change should do for a first prototype | 14:17.35 |
| paulgardiner | Back to the fz_run_display_list call: I haven't done anything towards separating the annotations from everything else, so I assume I'm regenerationg the whole display list. | 14:17.47 |
| | Ah right. And for generating the display list too? | 14:18.13 |
| tor8 | look at pdf_run_page_with_usage in pdf/pdf_interpret.c | 14:18.23 |
| | in shortened form it's basically: run_page() { run(content); for each annot: run(annot->content); } | 14:19.06 |
| | that loop could be hoisted up to the app, so it enumerates which annots to render | 14:19.37 |
| | and can then make a separate display list for each one (or render on the fly, as is also possible) | 14:19.59 |
| | my thinking was to have the app render the page->content into one pixmap, and each annot->ap into a pixmap of its own, and compose them at blitting to screen time | 14:20.59 |
| | the page transparency groups thow a few spanners into the wheel in the general case though :( | 14:21.48 |
| paulgardiner | Ok. Makes sense. And so the partial rendering and partial display list construction goes hand in hand. So I should not worry about either for an inital version? | 14:23.24 |
| tor8 | I don't think you should, no | 14:24.45 |
| | keep in mind, the ios app doesn't even use display lists :) | 14:25.06 |
| paulgardiner | Oh right. :-) | 14:25.28 |
| | Ok. Thanks for your help. I'll see if I can some of the simpler cases of checkboxes going. | 14:26.04 |
| henrys | marcosw_:there were some disk space problems on mac pro - I've made enough space but I don't know if I've found the actual problem. | 14:41.31 |
| kens | mac pro seems to be giving a bit of trouble today. | 14:47.43 |
| henrys | I think it should be okay now but I'll keep an eye on it. | 14:57.12 |
| robin_watts_mac | paulgardiner, tor8: just read logs. | 15:05.12 |
| ray_laptop | morning, all | 15:05.21 |
| kens | Hi ray | 15:06.24 |
| henrys | marcosw:I'll be a little late today if you want to have the meeting. Does 10:00 work for you? | 15:09.41 |
| tor8 | robin_watts_mac: good evening! | 15:12.14 |
| robin_watts_mac | evening. | 15:14.29 |
| henrys | well we are down to 6 customer bugs. | 15:22.17 |
| kens | oooh :-) | 15:22.39 |
| henrys | and I think tor8 should make his an enhancement. | 15:23.18 |
| | as it depends on an enhancement (freetype) | 15:24.58 |
| chrisl | Well, strictly speaking, one of mine is (IMHO) an enhancement, too. | 15:25.48 |
| | #689691 | 15:26.32 |
| henrys | chrisl:go ahead and change it. | 15:27.19 |
| | in a few more minute the only customer bugs will be mvrhel's ;-) | 15:27.39 |
| | chris:don't know if you saw that go ahead and change it. | 15:28.13 |
| | chrisl ^^^ | 15:28.30 |
| chrisl | Yes, I saw it - I was just typing "thanks" when the mysterious disconnect happened.... | 15:28.44 |
| henrys | be back in an hour or so. | 15:28.58 |
| paulgardiner | Robin_Watts: Hi, if you're still here. | 15:38.09 |
| robin_watts_mac | paulgardiner: hi. just going to bed. | 16:14.16 |
| | 6am flight tomorrow (8 hours time) | 16:14.29 |
| ray_laptop | oops. I think my laptop is about to crash again. | 16:34.50 |
| | the toolbar is non-responsive | 16:35.02 |
| | or maybe not. Restarting just in case | 16:35.25 |
| mvrhel | henrys: are you serious. all customer bugs will be closed except for the ones in my lap | 17:05.38 |
| kens | Nope, I have one too | 17:06.10 |
| mvrhel | I see one for kens, chrisl, me, ray and alex | 17:06.29 |
| | and me with 3 actually | 17:06.48 |
| m2j | Hi, to the MuPDF devs, or others, who know about: I've seen the pipdf project aiming to provide Python bindings for MuPDF. Still there is no released code. Do you know, if someone is working at this actively? | 17:18.13 |
| kens | Heading off, have a great weekend everyone. | 17:49.30 |
| henrys | mvrhel:you'd be terrible being a shell game dealer | 18:01.31 |
| mvrhel | henrys: yes. that is probably true | 18:01.58 |
| | cool got the hl clip fill rect working now and the gradient code | 18:09.32 |
| | it is always interesting to work on code in the morning that you wrote late the night before and you wonder, ok was I half asleep when I wrote this | 18:10.22 |
| | looks like I have a goof up on my triangle fill values though in the gradient. need to track that down | 18:17.20 |
| | bbiaw | 20:14.19 |
| | Forward 1 day (to 2012/03/24)>>> | |
IRC Logs