| | <<<Back 1 day (to 2012/02/19) | 2012/02/20 |
| rayjj | I committed the image_rotation change (zimage.c). Interestingly, many of the "regressions" are probably just indeterminisms because I saw PCL files that changed and zimage is ONLY PS/PDF images :-/ | 06:45.56 |
| | in any case, the differences were all trivial and I don't think qualify as regressions. | 06:46.28 |
| | now to send the change over to cust 532 for performance testing and their QA. | 06:47.20 |
| | my laptop is somewhat more stable (knock wood). Still have to find out what's causing the crashes. I may go back to a restore point :-( | 06:48.23 |
| chrisl | Good morning kens - how was the skiing? | 07:57.03 |
| kens | Hi chrisl, very good thanks. Weather could have been better, but the snow was good. | 08:02.36 |
| | Now I have to catch up with last week :-( | 08:02.47 |
| chrisl | I think there was only one or two things that came up for you - it was a relatively quiet week...... | 08:03.39 |
| kens | 303 emails :-( | 08:04.03 |
| | Though yes, I'm sure most of it is nothing to do with me. | 08:04.21 |
| chrisl | But you shouldn't have to read them all! | 08:04.27 |
| kens | Skim them at least | 08:04.36 |
| | chrisl did you figure out how to get to the Doubletree from the airport ? | 08:33.24 |
| chrisl | Not yet - I'm only just sorting out my parking at heathrow! | 08:34.35 |
| kens | Ah, I just got as far as Miles's mail in my backlog, and couldn't see if it had a shuttle. It has a trolley to burlingame, so I guess it does. | 08:35.07 |
| | OK, it says there is a 24-hour complimentary bus from SFO | 08:36.09 |
| chrisl | Oh, good. I thought there was - I think I remember seeing it waiting for our "normal" bus. I seem to be terribly ill-prepared for this staff meeting trip :-( | 08:37.06 |
| kens | I know the feeling.... | 08:37.18 |
| | Did you get a call from Viurgin Atlantic ? | 08:37.28 |
| chrisl | No. Courtesy call, was it? | 08:37.47 |
| kens | Courtesy cum sales pitch | 08:37.56 |
| | I#'m tempted by the upgrade to premium on return | 08:38.14 |
| | ~£200 | 08:38.20 |
| chrisl | Yeh, I got that call last trip. | 08:38.34 |
| kens | I get them *every* trip | 08:38.43 |
| | This time they mentioned the price of the upgrade, and that its only available to silver frequent flyers... | 08:39.10 |
| chrisl | Oh, well, you've been Silver Flying Club member longer than me..... | 08:39.11 |
| | Still would be nicer if they'd let us use our miles to upgrade! | 08:39.38 |
| kens | Sure, but the money upgrade comes with tier points too, which is useful | 08:40.02 |
| | Down to 136 emails now. Time for coffee | 08:40.46 |
| chrisl | I wonder how busy the return flight will be. | 08:40.55 |
| kens | The salesman claimed it was getting gull. | 09:00.16 |
| | full | 09:00.19 |
| chrisl | Yeh, no isle seats in premium economy - I'll stick to my isle seat in economy..... | 09:03.46 |
| kens | Hmm, I guess so too. Not interested in non-aisle seat, even if it is premium | 09:04.09 |
| chrisl | I just phoned and asked - I'd have upgraded if I could get an isle seat | 09:05.06 |
| kens | Right, well that saves me doing it, thanks :-) | 09:05.18 |
| Robin_Watts | Exit row seats can be had for 75 quid. | 09:14.59 |
| kens | Also tempting. | 09:15.09 |
| | Did you call them Robin ? | 09:15.15 |
| Robin_Watts | and I was told 304 quid for PE. | 09:15.18 |
| | No, they called me yesterday. | 09:15.24 |
| kens | Ah, same as me. I'm sure the return was 200 though, outbound was more | 09:15.37 |
| Robin_Watts | tor8: ping | 13:16.35 |
| tor8 | morning robin | 13:16.43 |
| Robin_Watts | Morning | 13:16.48 |
| | I've just pushed a new branch to my repo on casper. | 13:16.58 |
| | 'images'. | 13:17.02 |
| | Could I trouble you to look over it when you have a second. | 13:17.16 |
| tor8 | argh, ant doesn't rebuild resource xml files unless you do clean... | 13:17.17 |
| Robin_Watts | ? | 13:17.19 |
| tor8 | ant debug install doesn't update the layout files etc | 13:17.50 |
| | android app | 13:17.54 |
| Robin_Watts | craptastic :( | 13:18.29 |
| tor8 | I see you put the resolution in xps/cbz-specific subclasses of fz_image | 13:20.43 |
| | oh right, because we don't have that until we actually parse the content | 13:21.20 |
| Robin_Watts | Yes. | 13:21.33 |
| tor8 | that dance in xps_load_image, just to get the resolution? | 13:22.09 |
| Robin_Watts | 'dance' ? | 13:22.50 |
| | Currently in xps and cbz I'm just loading and decoding at interpret time. | 13:23.15 |
| | There is no benefit for xps or cbz. | 13:23.23 |
| | The benefit comes for pdf. | 13:23.32 |
| tor8 | right! | 13:23.43 |
| Robin_Watts | We *could* write simple code to read the headers of the formats just enough to get the resolutions out. | 13:23.54 |
| tor8 | I was misreading the try/catch | 13:23.57 |
| Robin_Watts | Then we could get benefits for xps/cbz too. | 13:24.03 |
| tor8 | idea, shouldn't the get_pixmap callback take x,y params too if we only want a subset of the image for a band? | 13:26.18 |
| | or those w/h are for fast downscaling when loading jpeg? | 13:26.32 |
| Robin_Watts | The w and h supplied to the get_pixmap are the 'target size'. | 13:27.24 |
| | So they can subsample. | 13:27.29 |
| | Possibly we could extend this by passing in a rectangle later too to allow partial decode. | 13:27.55 |
| | tor8: See anything in there you dislike? Stream Handling in particular ? | 13:46.27 |
| | Am saning it now. | 13:46.55 |
| tor8 | you hid the icky bits with a callback so I'm probably fine with it :) | 13:47.08 |
| Robin_Watts | The problem I still need to solve is that once images have been converted to pixmaps, they can never be evicted from cache. | 13:47.29 |
| tor8 | inline images with pdf_open_inline_stream, how does that work? | 13:50.50 |
| Robin_Watts | very nicely, thank you :) | 13:51.08 |
| | Previously, whenever we hit an image we used to open a stream, and setup a bunch of filters, then decode the data from that stream. | 13:52.26 |
| | Now, we open the stream, and setup a bunch of filters, but pass in a pointer to an image_params struct. | 13:52.55 |
| | The fact that we pass in that struct means that the filter building code stops on the last filter, and just records the details of the filter that would have been used into the struct. | 13:53.37 |
| tor8 | so far I'm with you | 13:54.21 |
| Robin_Watts | We then read all the data from the stream into a buffer, and close the stream. That buffer, together with the image_params goes into a pdf_image. | 13:54.25 |
| tor8 | ah, you store the buffer! | 13:54.52 |
| Robin_Watts | When the pdf_image is asked for a pixmap, it opens the buffer with the filter as specified by the image_params. | 13:54.58 |
| | yes. | 13:55.00 |
| tor8 | you talked about file locking and such last week, that had me confused/blinded :) | 13:55.17 |
| Robin_Watts | That can be done (I believe), but it's a future step. | 13:55.35 |
| | (and that won't be done for inline images) | 13:55.44 |
| tor8 | I'm reluctant to take that step though, it messes a bit too much with threads and locking | 13:56.18 |
| Robin_Watts | I believe it shouldn't need any changes to the locking we have now. | 13:56.39 |
| tor8 | alright, I have no objections to the image branch at a first glance through it | 13:56.49 |
| Robin_Watts | (but will cause contention) | 13:56.51 |
| | tor8: cool. | 13:56.57 |
| | Just looking at the diffs now. All look like subsamplign differences so far. | 13:57.13 |
| tor8 | I think we should back out the file locking though, it's just going to confuse me down the line. on the other hand, mupdf is fairly mature that those things will probably not change anymore. | 13:57.35 |
| | due to the scale_num/denom in dctdecode? | 13:58.07 |
| Robin_Watts | yes. | 13:58.36 |
| | The fact that the output from that goes into the linterp stuff. | 13:58.58 |
| | oh, I need to reenable jpx stuff. | 14:00.05 |
| tor8 | Robin_Watts: can you get paul on irc? there's a few things about the android app I'd like to ask him about now that I finally got the dev environment up | 14:01.45 |
| Robin_Watts | sure. | 14:01.52 |
| tor8 | that was quick :) | 14:02.44 |
| | hi paul | 14:02.47 |
| paulgardiner | hi Tor, ChatZilla seems to do all the signing in for me, otherwise it might have been 10 mins or so :-) | 14:03.33 |
| Robin_Watts | paulgardiner: I've just published 'pg_android' to the main repo. | 14:03.33 |
| paulgardiner | thanks | 14:03.50 |
| Robin_Watts | np. | 14:03.54 |
| tor8 | paulgardiner: I'm testing it on my galaxy tab 10.1 and there are a few things I want to ask you about | 14:04.21 |
| paulgardiner | Oh ok. Nothing disasterous I hope. | 14:04.46 |
| tor8 | first one is probably trivial once you've read the android docs ... if you don't know I can start digging but it could save me some time | 14:05.06 |
| | I've got this funny button in the status bar with a menu for "Stretch to fill screen" and "Zoom to fill screen" | 14:05.34 |
| | I assume this is because it's missing some layout xml thing for tablet sized devices | 14:05.49 |
| | the first option pixel doubles the app, like running iphone apps on an ipad | 14:06.12 |
| | the second option (which is default) scales up the UI so everything looks fine | 14:06.25 |
| paulgardiner | Hmmm. I don't know what that is. I guess we want the option not to be offered. | 14:08.43 |
| tor8 | yeah, I'll look into it later then | 14:09.03 |
| paulgardiner | Thanks. I'll take a quick look too and let you know if I find anything. | 14:09.32 |
| tor8 | the second problem is more worrying. I tried changing the margin for the seekbar to 0 because having it hovering in the middle of the screen looked a bit odd. when I did that, the tiled background started flickering black when the buttons.xml fade animation was playing at the same time as the page is scrolling | 14:10.14 |
| | I'm assuming animation framework bugs here :) | 14:10.32 |
| | though the fade animation is rather pointless ... the frame rate is disappointingly bad on my tablet, it looks like it's somewhere between 10-15 fps only :( | 14:11.48 |
| | the rendering is blazingly fast, it's just the screen refresh when scrolling that's atrocious | 14:12.20 |
| paulgardiner | That's strange too. I can't think what would make that flicker. | 14:12.22 |
| | I noticed that that about the screen refresh compared to the iOS version too. I wonder if there is a predefined shortest time for callbacks to get fired. Perhaps that can be set lower. I haven't yet found anything like that. | 14:14.44 |
| tor8 | is the scrolling animation tied to callbacks or something the framework provides? | 14:15.16 |
| Robin_Watts | <supports-screens android:smallScreens="true" | 14:15.27 |
| | android:normalScreens="true" | 14:15.29 |
| | android:largeScreens="true" | 14:15.31 |
| | android:anyDensity="true" /> | 14:15.33 |
| | Add: android:xlargeScreens="true" ? | 14:15.40 |
| paulgardiner | Robin_Watts: that sounds hopeful. | 14:15.58 |
| | The scrolling animation is tied to callbacks. | 14:16.24 |
| Robin_Watts | That may mean we need API level 9 rather than 8 though. | 14:17.17 |
| | http://stackoverflow.com/questions/4709291/android-no-resource-identifier-found-for-xlargescreens | 14:18.05 |
| | Maybe we should look at the "layout-xlarge folder" option, but I don't have a clue what that means. | 14:18.30 |
| paulgardiner | There are two choices when triggerring a callback. You can specify a time or not. I assumed the method which doesn't require a time meant "as soon as possible", but it might be worth trying the other method with duration 0. | 14:20.24 |
| | I also wondered if the painting was expensive because the views were assumed to have transparency, so I overrode the isOpaque method for all of them, but that didn't help. | 14:22.08 |
| Robin_Watts | Ah. Maybe just mkdir android/res/layout/xlarge ? | 14:22.28 |
| paulgardiner | It's a shame to have to go up an API level just to prevent it offerring an option we don't want. I wonder if there's another way. | 14:24.40 |
| tor8 | paulgardiner: it's probably event/callback pumping delays. the ios core animation layer runs in a separate thread and does all sorts of funky stuff with caching bitmaps in opengl textures. | 14:24.48 |
| | and I think the android ui does something similar with drawing regular bitmaps. | 14:25.15 |
| Robin_Watts | paulgardiner: If I'm reading it right, then just creating the directory should do the trick. | 14:25.18 |
| Robin_Watts | lunches. bbs. | 14:25.48 |
| paulgardiner | Robin_Watts: oh right. That would be great | 14:26.14 |
| | tor8: Interesting. Not sure how to move much of it onto another thread. You aren't supposed to call layout or measure directly, so a lot would still be done in the UI thread. | 14:30.31 |
| tor8 | paulgardiner: yeah, I don't know what to do here. I'm no expert on android but I can't imagine adding more thread contention will help us here. | 14:32.45 |
| | especially since we aren't supposed to call layout and repaint directly | 14:33.02 |
| | opengl es is probably the best way to get great performance, but that's a lot of work and I have no idea how that integrates with the regular android widgets | 14:34.10 |
| paulgardiner | It may be all down to the delay between posting a callback and its being triggered. I don't know if there's another mechanism that can be used. | 14:36.34 |
| | I think you're right that opengl would solve it, but as you say integrating with other widgets could be hellish. | 14:37.19 |
| | Lots of animations on the HTC desire seem a little clunky, but the browser seems to manage smooth animation. | 14:38.25 |
| tor8 | that flickering is difficult to get a handle on, can you reproduce it? | 14:39.17 |
| | paulgardiner: the ViewAnimator animations, are they done by callbacks too? I changed the duration to 0.5s and I see about 5 discrete jumps so maybe it is the drawing performance rather than callback latency. | 14:43.37 |
| | paulgardiner: turning off the tiled background doubled the framerate... | 14:45.30 |
| | for scrolling, but fading in and out is still the same slow speed | 14:46.25 |
| paulgardiner | Really! I thought I tested that, but maybe not. | 14:47.31 |
| | The scrolling is done with callbacks. The fading is done by requesting the animation from the system. | 14:49.37 |
| tor8 | yeah, it's much faster at scrolling with a plain background | 14:50.07 |
| | the fading animation isn't affected though | 14:50.17 |
| paulgardiner | That's terrible. A lot of the time the textured background isn't even visible. | 14:51.12 |
| tor8 | the scrolling speed is bogged down while the animation is playing as well. I'm guessing the image drawing/compositing is not very optimal here :( | 14:51.51 |
| | did you flag everything opaque, or did you back that out when you didn't see any difference? | 14:52.16 |
| paulgardiner | I purposely put in the isOpaque overrides, to make sure the system wouldn't consider the views as transparent and hence need the background rendered beneath them | 14:52.35 |
| tor8 | great! | 14:53.00 |
| | is there an easy way to turn off the ViewAnimator? see if that may affect things. | 14:53.50 |
| paulgardiner | I did read something about it being only later versions of android that took notice of whether views were opaque. | 14:53.52 |
| tor8 | I'm running android 3.2 | 14:54.11 |
| | heh. if I change to the "Zoom to fill screen" option, it scrolls at 60 fps! | 14:54.39 |
| | of course, it's all a blurry mess | 14:54.46 |
| paulgardiner | Maybe the version for which the app is compiled has an effect - maybe grasping at straws. | 14:54.50 |
| | :-) | 14:55.05 |
| tor8 | but I think that rules out the callbacks being the problem at least :) | 14:55.22 |
| Robin_Watts | tor8: Did you try creating that directory ? | 14:55.35 |
| paulgardiner | Sorry, not sure what "turn off the ViewAnimator" means. Get rid of bounce back? | 14:55.36 |
| | yeah, that's nice to know that the callback mechanism isn't in the frame. | 14:55.56 |
| tor8 | res/layout/buttons.xml uses a ViewAnimator thing for the fade in/out of the buttons layer | 14:56.05 |
| | Robin_Watts: just mkdir, or mkdir + xml? | 14:57.02 |
| Robin_Watts | I'd try just mkdir to start with. | 14:57.14 |
| tor8 | just mkdir doesn't have any effect | 14:57.47 |
| | and xlargeScreens fails to build | 14:58.21 |
| Robin_Watts | Try copying the contents of layout into layout/xlarge ? | 14:59.05 |
| Robin_Watts | is guessing here. | 14:59.09 |
| tor8 | no change | 15:00.22 |
| paulgardiner | Oh yes, the ViewAnimator. In an earlier version, I used an animation. It might not be too difficult to resurrect that way of doing it. | 15:02.44 |
| tor8 | well, it just flips between two views right? | 15:03.09 |
| paulgardiner | One view really. I added a dummy completely invisible one just so that I could use the ViewAnimator. | 15:04.23 |
| tor8 | I'm okay with ditching the animation altogether if that simplifies things | 15:05.09 |
| | the iOS app only has it because it "comes for free" :) | 15:05.31 |
| paulgardiner | Is the problem with it that it gives a clunky animation, or were you also thinking that it might be slowing the scrolling? If the former then could just set the animation duration to 0. | 15:07.21 |
| tor8 | both. I tried setting the duration to zero and I still get the black background flickering for one frame, which is most odd. | 15:08.30 |
| paulgardiner | On the other hand, going back to the direct use of an animation rather than using the ViewAnimation might possibly give a smoother fade. | 15:08.35 |
| tor8 | the animation looks nice and smooth if I use the pixel doubling mode, but in regular display a 200ms fade (which is the same duration as iOS animations) there are only one or two intermediate frames being drawn (so 2-3 frames over the 200ms duration) | 15:10.23 |
| paulgardiner | So do you think it's because it's 4x less work in pixel doubling mode? | 15:12.15 |
| Robin_Watts | I saw a comment on stackoverflow that animations can flicker due to shortage of memory. | 15:12.46 |
| | Presumably in pixel doubling mode it's much less memory to hold the intermediate stuff. | 15:13.15 |
| | tor8: Why is JPX done differently to the other formats? | 15:14.15 |
| paulgardiner | That would make a lot of sense. Not easy to see an easy place to save memory though. | 15:22.41 |
| | Could half the res of the main bitmaps, and use HQ even when zoomed completely out, perhaps. | 15:23.45 |
| Robin_Watts | Morning scott-san | 15:25.36 |
| kens | Hello scott-san | 15:25.39 |
| scott-san | Hi Guys. Just checking to see what's happening and getting my day started. Looking forward to seeing you guys at the end of this week | 15:26.16 |
| paulgardiner | Oh! It might be better to fade out the parts of the UI separately, rather than the parent view. Depends how Android handles it. | 15:26.21 |
| Robin_Watts | scott-san: Yeah, you too. | 15:26.43 |
| scott-san | Take it easy and have a good evening guys! | 15:27.16 |
| tor8 | Robin_Watts: because the stream pipeline doesn't know that it's an image, so there's no way to feed it the colorspace | 15:27.34 |
| Robin_Watts | tor8: Ah. | 15:27.52 |
| tor8 | Robin_Watts: the black flickering background if I set the seekbar margin to 0 is there also in the pixel doubled mode | 15:28.10 |
| Robin_Watts | I think I may have inadvertently fixed that with the fz_image_params struct :) | 15:28.38 |
| paulgardiner | Does making the margin to 0, change that control from being partly transparent to being totally opaque?... and hence when 0 the fade animation causes the control to go from transparent to opaque. Is the glitch at the fully-visible end of the animations? | 15:32.45 |
| | Sorry, badly written. I mean, with margin 0, the animation has to make the transit from opaque to transparent, whereas with non 0, the slider is always transparent, even when fully visible. | 15:37.53 |
| tor8 | well, the seekbar already has a semi-transparent background | 15:39.00 |
| | the flickering happens a few times in the transition, sometimes at the last frame leaving the screen with a black backdrop | 15:39.35 |
| paulgardiner | Ok. Probably wouldn't have helped much in fixing it even if that had been the reason. | 15:40.32 |
| | Looks like adding xlargeScreens="true" and moving to API 9 may be the only way to get rid of the choice of modes. | 15:48.53 |
| Robin_Watts | Did you see the stackoverflow link I posted earlier? | 15:51.28 |
| paulgardiner | Yeah. Haven't read it to the end yet. | 15:54.23 |
| | There was only a bit more. :-) Hmmm, so is that what Tor tried earlier? | 15:56.38 |
| | I think it should be layout-xlarge rather than layout/xlarge. | 15:58.42 |
| | tor: may be worth having another go. | 15:59.03 |
| Robin_Watts | oh, d'oh. | 15:59.10 |
| paulgardiner | Possibly may still need to raise the API level, though. | 16:02.07 |
| Robin_Watts | I thought the point of using the directory was that we wouldn't need to raise the API level. | 16:02.27 |
| paulgardiner | Yeah, might work, and certainly the first thing to try, but at API 8 the folder might be ignored. Just guessing. | 16:09.21 |
| | tor8: I've changed the fade to directly use an animation instead of ViewAnimator. I'll email a patch to you in case you want to try it. | 16:47.37 |
| Robin_Watts | Morning mvrhel. Good skiing ? | 16:49.36 |
| mvrhel | it was very good | 16:49.44 |
| | we had about a foot of new snow the last day | 16:50.03 |
| Robin_Watts | I made a gs change last week in your area, that you might want to check over. | 16:50.10 |
| | Nice. | 16:50.12 |
| mvrhel | ok | 16:50.28 |
| Robin_Watts | d00354a | 16:50.39 |
| mvrhel | oh interesting. I am surprised that was in there that long | 16:51.45 |
| | thanks | 16:51.58 |
| Robin_Watts | no worries. The change seemed plausible to me, but there was a certain amount of fumbling going on. | 16:54.00 |
| henrys | kens must have missed comment #1 in 692860 | 16:56.55 |
| kens | Did I ? | 17:06.52 |
| | Let me look | 17:06.56 |
| henrys | no big deal ... | 17:07.19 |
| kens | Oh no, I saw it but I was puzzled by his second response. Once he replies I'm going to stop working on it | 17:07.21 |
| | Until we hear back from Scortt anyway | 17:07.35 |
| henrys | okay it seemed that you were proceeding sorry. | 17:08.12 |
| kens | Bascially I just want the problem clarified if its going to be mine (he changed the component to PDF write which assigned it to me) | 17:08.22 |
| | But since you are here :-) | 17:08.44 |
| | Can you reduce that raster pattern problem to just one pattern ? | 17:08.54 |
| | #692853 | 17:09.07 |
| | I'm getting lost in the maze figuring out which pattern is doing what | 17:09.42 |
| henrys | oh sure, let me get throught my mail first. | 17:09.42 |
| kens | No rush, I'm off shortly | 17:09.50 |
| henrys | wow an xps bug. | 17:11.48 |
| kens | Yes, I saw that, and quickly ignored it :-) | 17:12.07 |
| | But given who its from.... | 17:12.32 |
| | THere's a separate mail to support too | 17:12.39 |
| tor8 | paulgardiner: the fade animation is indeed smoother now, but I get an one frame of black background at the very end of the animation if I have the button layer visible and start scrolling so that the buttons fade out while I'm scrolling. very odd. | 17:14.04 |
| mvrhel | brb | 17:19.37 |
| kens | Robin_Watts : ping | 17:22.55 |
| Robin_Watts | pong | 17:23.04 |
| kens | Reading back irc logs | 17:23.12 |
| | Do you think Scott could fit me in for dinner too ? | 17:23.21 |
| | After Alcatraz | 17:23.30 |
| Robin_Watts | Yes, you're in. | 17:23.54 |
| kens | Ah, thanks :-) | 17:24.01 |
| | Wasn't sure from teh log | 17:24.05 |
| Robin_Watts | I accepted on all our behalves. | 17:24.11 |
| | :) | 17:24.16 |
| kens | Thanks (on my behalf) | 17:24.22 |
| Robin_Watts | (behalfes? behalves is probably right, but it looks odd) | 17:24.49 |
| kens | No idea, maybe there is no plural | 17:24.59 |
| Robin_Watts | behalves is supposedly proper (1986 Websters) | 17:26.13 |
| henrys | kens:I do have a copy of swiftview now and from what I've seen so far it is just text and everything else is rasterized. rasterop and transparency is rarely an issue with text so maybe not a bad choice. | 17:26.20 |
| kens | I won't argue.... | 17:26.24 |
| | henrys we can do better than that :-) | 17:26.44 |
| | But maybe not as fast | 17:27.03 |
| | Actually, I take tha back, it will be as fast | 17:27.19 |
| | And a more scalable PDF file in the general case | 17:27.38 |
| | Probably smaller too | 17:27.45 |
| | We can talk about it at the meeting ? | 17:28.03 |
| henrys | yea I'll add it to the agenda. | 17:29.12 |
| kens | Good plan. | 17:29.18 |
| | I've just seen the time. Heading off now. | 17:29.36 |
| | Goodnight all | 17:29.46 |
| mvrhel | what night/day are you guys going on the Alcatraz tour | 17:33.33 |
| chrisl | mvrhel: Saturday, I think | 17:35.32 |
| mvrhel | cool. I need to do that one of these trips. Ethan really wants to go | 17:36.00 |
| paulgardiner | tor8: Odd indeed. At least a little progress I suppose, but strange. Sounds like the glitch is at the point at which the buttons are at the point of calling setVisible(View.INVISIBLE). | 17:37.49 |
| Robin_Watts | mvrhel: You need to book Alcatraz tickets well in advance (especially for the night tour). | 17:38.11 |
| | I tried to get Scott and his daughter tickets last week and they were gone. | 17:38.26 |
| paulgardiner | Aagh! Trying to type too quickly. | 17:38.35 |
| | tor8: Is it still only when the margin of the seekbar is set to 0? | 17:49.02 |
| tor8 | paulgardiner: no, it's always now | 17:50.24 |
| paulgardiner | :-( | 17:51.34 |
| henrys | mvrhel:I'm thinking about registering for the Alcatraz triathlon, maybe if I took the tour first I'd change my mind. | 17:53.11 |
| Robin_Watts | Dig/Run/Swim. | 17:53.23 |
| mvrhel | ha | 17:53.29 |
| henrys | I think digging is going to be the slow leg. | 17:54.33 |
| Robin_Watts | The hardcore athletes do that leg with just a spoon. | 17:56.11 |
| | But these days it's carbon fibre of course. | 17:56.27 |
| henrys | no drafting either. | 17:58.50 |
| Robin_Watts | :) | 17:59.05 |
| henrys | I'm watching the new tv show alcatraz crazy about it. | 18:10.05 |
| | sorry not so crazy about it. | 18:10.16 |
| | gosh those are big improvements without compression. | 18:17.20 |
| | bbiab | 18:27.18 |
| Robin_Watts | henrys: Excellent. I was estimating 20% of the time being spent compressing into the clist, so if that's dropped to 4% or so for copying into the clist instead, that's bang on. | 19:08.25 |
| | And with Rays change we should be sorted for speed. Thank heavens... | 19:08.41 |
| | tor8: ping? | 19:08.45 |
| tor8 | Robin_Watts: yes? | 19:09.18 |
| Robin_Watts | I've made jpx files work again in the image branch. | 19:09.37 |
| | They are still special cased for now. | 19:09.48 |
| | and loaded immediately. | 19:09.56 |
| | But I believe we can fix that now, because we can pass the colorspace in in the image_params struct. | 19:10.13 |
| | So, the pressing issue now is one of caching. | 19:10.28 |
| | Do you have a few minutes to talk this through? | 19:10.39 |
| tor8 | sure, but bear in mind I haven't studied the caching you wrote very much | 19:11.35 |
| Robin_Watts | OK. In the original code, we decoded to pixmaps instantly. | 19:12.30 |
| | and those were put into the store. | 19:12.40 |
| | So subsequent reuses of the same image would be shared. | 19:12.57 |
| | and they could never be flushed while the display list held onto them. | 19:13.28 |
| | In the current code, I've directly replaced the pixmaps in the store with images. | 19:13.45 |
| tor8 | yes. they only get evicted if the only owner is the store. | 19:14.00 |
| Robin_Watts | So images go into the store (and display list) and the only thing they hold initially is the compressed data. | 19:14.31 |
| tor8 | right, so you want to (or do already) cache the image->get_pixmap result | 19:14.36 |
| Robin_Watts | Every image has a pointer internally to a pixmap, in which I store the last decoded version. | 19:15.18 |
| | This is only ever replaced when someone asks for a pixmap which is bigger than the one we have cached. | 19:15.42 |
| | currently there is no way of evicting pixmaps once we have them. | 19:16.02 |
| | I could move to a scheme where I don't store the pixmap pointer in the image and just put it in the cache. | 19:16.37 |
| | But what do I use as the key in the cache ? | 19:16.46 |
| tor8 | would it be possible to use the image pointer as the key? | 19:17.28 |
| Robin_Watts | I could use the dict (but then the images and the pixmaps would have the same key, and that's probably bad, right?) | 19:17.54 |
| tor8 | ideally we'd want to cache the scaled and color converted pixmaps if we have the memory for it | 19:17.57 |
| Robin_Watts | Oh, use the image pointer itself. | 19:18.12 |
| tor8 | just worried about what happens to the key if the image gets evicted | 19:18.34 |
| | if that memory is ever reused we'll be in trouble unless we evict the pixmaps that are derived from the image as well | 19:19.17 |
| Robin_Watts | Do we have a function to tell the hash table to evict everything with a given key ? | 19:19.21 |
| tor8 | Robin_Watts: we could add one if nothing else :) | 19:19.34 |
| Robin_Watts | Linear probing may make that expensive. | 19:19.55 |
| tor8 | I also implemented an AA-tree (self balancing binary tree) the other week if you think that may be a better data structure than a hashtable | 19:20.00 |
| Robin_Watts | I like splay trees, personally. | 19:20.21 |
| | but I suspect a hash table is better here. | 19:20.32 |
| | We may want to move to a hash table with no linear probing though. | 19:20.45 |
| tor8 | never implemented a splay tree, but they're simpler than red-black trees aren't they? | 19:20.49 |
| | the linear probe hash table has one good property -- no mallocs for the individual buckets | 19:21.15 |
| | but other than that -- not much | 19:21.19 |
| Robin_Watts | Simple binary trees, but when you 'find' a node, you perform a 'move to root' with it, where you drag it back to the root using rotations. | 19:21.26 |
| | Very fast to do, and it means that recently used stuff stays near the top. | 19:21.42 |
| | A hash table with no linear probing doesn't mean any more mallocing necessarily. | 19:22.01 |
| | Every hash entry just needs to have a 'next' pointer as part of it. | 19:22.18 |
| tor8 | in our storable case, we could make the key and 'next' pointer as part of the fz_storable | 19:22.37 |
| | so yeah, we could definitely do that | 19:22.46 |
| Robin_Watts | Indeed. | 19:22.46 |
| | OK, so I'll move to caching the pixmaps tomorrow. | 19:23.11 |
| | (I'll do whatever the minimal change to the hash table is) | 19:23.27 |
| | The mupdf customer is reporting that the new code is much slower than the old one. | 19:24.02 |
| | and from the look of the screenshots of the profiler he's sent, on the page he's picked, the new code is spending lots of time in pdf_loadshading. | 19:24.34 |
| | Where the old code doesn't show any time there at all. | 19:24.42 |
| | I can't see any visual differences in the screenshots between the old and new versions though. | 19:25.18 |
| | so it's not obviously "old version didn't do shadings". | 19:25.35 |
| | Unless maybe the shading is very subtle indeed. | 19:25.46 |
| tor8 | odd, we haven't changed the shading code in ages | 19:26.29 |
| | and the loading shouldn't be a bottleneck ever | 19:26.52 |
| | unless there's a subtle bug somewhere | 19:27.03 |
| Robin_Watts | I noticed something today. | 19:27.25 |
| | We 'guess' the length of streams. | 19:27.34 |
| | Then we make a buffer of that size, and try to read the data in. | 19:27.49 |
| tor8 | right | 19:28.00 |
| Robin_Watts | If the number of bytes we try to read in is > 0 we go around the loop, make more space in the buffer and try to read again. | 19:28.20 |
| | So if we guess right, we fill the buffer on the first attempt. | 19:28.41 |
| tor8 | this is fz_read_all? | 19:28.44 |
| b0fh_ua | Hello! I have postsrcipt document, how do I resize it from A4 to A5 and then create PDF to read on Kindle? | 19:28.46 |
| Robin_Watts | We then make it 50% bigger, fail to read any more, and exit, wasting 1/3 of the memory :( | 19:29.17 |
| | Yes. | 19:29.19 |
| tor8 | we only make it bigger if we ran out of space | 19:29.38 |
| | if (buf->len == buf->cap) | 19:29.46 |
| Robin_Watts | Right. | 19:29.50 |
| | And cap is set to our first guess at len, right? | 19:30.14 |
| tor8 | yeah, it's initialised to the value passed into fz_new_buffer | 19:30.40 |
| | oh right, I see what you mean! | 19:31.04 |
| Robin_Watts | Right. So if we guessed the buffer size properly to start with (like say, reading it out of a Length field for an Image) then we end up... | 19:31.08 |
| tor8 | for non-compressed streams where we actually have an accurate initial guess we're wasting 1/3 of memory! | 19:31.27 |
| Robin_Watts | Indeed. | 19:31.34 |
| tor8 | fz_new_buffer(ctx, initial + 1)? | 19:31.47 |
| Robin_Watts | And for compressed ones (like images) where we don't do the decompression. | 19:31.47 |
| | ha! | 19:31.52 |
| | Excellent fix! | 19:31.59 |
| tor8 | we may be able to look at stm->eof as well, but I don't think that one is accurate on all filters unless you try to read past the end | 19:32.53 |
| Robin_Watts | We could consider doing a 'fz_buffer_compact' or something that we could call if we were planning to keep a buffer around for any length of time. | 19:32.57 |
| tor8 | so it'd still be the same situation | 19:32.59 |
| Robin_Watts | That moves cap down to len. | 19:33.18 |
| | and reallocs. | 19:33.24 |
| tor8 | I don't trust realloc to be smart | 19:33.32 |
| Robin_Watts | Can it possibly be worse than not calling it at all? | 19:33.47 |
| tor8 | it's an extra memcpy | 19:34.04 |
| | but yeah, we could add a fz_trim_buffer call to realloc down to the actual len used | 19:34.30 |
| Robin_Watts | I believe the worst case is that realloc will say "well, it's already big enough, just return unchanged" | 19:34.33 |
| tor8 | and use that for the images that'll stick around | 19:34.40 |
| Robin_Watts | I don't believe anyone will have a realloc so crap that it'll malloc/memcpy/free without checking. | 19:35.08 |
| | (even memento gets that right :) ) | 19:35.27 |
| | Hey ray_laptop. Good news from 532. | 19:35.41 |
| tor8 | well, let's hope so :) | 19:35.42 |
| Robin_Watts | tor8: And people can tune that for their own targets if they want. | 19:35.58 |
| ray_laptop | Robin_Watts: yes, it sure is good news about cust 532. | 19:38.43 |
| | I assume you saw that I went ahead and committed the width/height swap changes after reviewing the bmpcmp | 19:39.11 |
| Robin_Watts | ray_laptop: I did. | 19:39.59 |
| ray_laptop | Robin_Watts: and I delivered that same patch to Eric. As you said, I sure hope that works as well for them as it did for me on the simulator | 19:40.00 |
| Robin_Watts | ray_laptop: Yeah. I mentioned in it my latest mail to him just in case he missed it as being buried in your previous mail. | 19:40.40 |
| ray_laptop | Robin_Watts: I also made sure I discussed it with Len this AM. Steve cancelled the holiday for them so he should be in. | 19:45.58 |
| | WOW !! Eric's results from the image rotation change on PWTTQ1CC are even better than 3.4x at 600 dpi 2-bit and 6.3x at 1200 dpi !!! | 20:40.03 |
| | s/even better/even better than my simulator results: / | 20:40.32 |
| kens | henrys (for the logs) I've not done any work on #692860, but the PDF file he sent looks the same to me as our rendering of the input. If there is a problem, I don't think its a pdfwrite problem. | 20:45.35 |
| kens | re3stores cloak | 20:45.47 |
| scott-san | Will one of you fellows give me the latest release for MuPDF? Thanks | 21:15.44 |
| | Forward 1 day (to 2012/02/21)>>> | |
IRC Logs