| | <<<Back 1 day (to 2013/05/21) | 2013/05/22 |
| VoipGuy | Hello all | 02:16.41 |
| vtorri | hey | 06:39.17 |
| | do you guys have some pdf examples with which you test mupdf ? I would like to test one which has links in it | 07:02.33 |
| tor8 | vtorri: the pdf reference manual has links | 08:22.32 |
| Robin_Watts | tor8: Morning | 09:24.34 |
| | A patch for review to solve some crashes when selecting text in android. | 09:24.49 |
| tor8 | Robin_Watts: looks fine | 09:34.46 |
| Robin_Watts | Ta. | 09:34.53 |
| tor8 | Robin_Watts: something else is still broken with search now though | 09:45.56 |
| | we can't search for phrases that are split by line breaks | 09:46.09 |
| | Robin_Watts: vtorris typo fix on tor/master | 09:49.40 |
| Robin_Watts | tor8: Where are you trying this? | 09:53.40 |
| tor8 | any file. pdfref17.pdf, page 50, search for "newline characters" | 09:55.12 |
| | I'm guessing we've got the "treat end of line as a space" logic wrong | 09:55.49 |
| Robin_Watts | tor8: I mean, windows/linux/android ? | 09:56.04 |
| tor8 | or I, seeing as I was the last one to change it | 09:56.08 |
| | windows/linux | 09:56.11 |
| Robin_Watts | ok, that means the error is probably not in android/jni/mupdf.c :) | 09:56.27 |
| tor8 | ugh. the x11/win32 viewer reimplements half of the search function itself. | 10:07.26 |
| Robin_Watts | pdfapp.c: match checks for the char being ' ' rather than it being whitespace | 10:10.06 |
| tor8 | Robin_Watts: I'm changing pdfapp.c to use the real search functions instead | 10:11.08 |
| Robin_Watts | so does the code in text_search.c | 10:11.14 |
| | in text_search.c match we should use: iswspace(charat(page, n)) rather than charat(page, n)== ' ' | 10:11.59 |
| | i'll leave you to it and go for a run. | 10:12.17 |
| vtorri | tor8, thank you | 12:15.52 |
| Weezey | the ghostscript with CentOS/RHEL 6.4 is 8.70 and has a stackunderflow error when converting PDF to TIFF (via hylfax) | 12:45.56 |
| | is there a repo that has a newer stable gs version or should I compile from source? | 12:46.17 |
| Robin_Watts | Weezey: Can't comment on a repo for centos. | 12:46.28 |
| | I'd compile from source. 8.70 is 5 years old or so. | 12:46.42 |
| | maybe 4.5 | 12:47.18 |
| Weezey | jeebus | 12:47.51 |
| | is latest git stable? | 12:48.01 |
| Robin_Watts | pretty much. | 12:48.17 |
| kens | Could pull the tagged 9.07 release | 12:48.50 |
| | and build that | 12:48.56 |
| Weezey | cool, thanks | 12:51.27 |
| tor8 | Robin_Watts: two fixes on tor/master | 12:53.41 |
| | actually, make that 3 | 12:53.55 |
| Robin_Watts | tor8: ok. | 12:55.53 |
| | tor8: All look good to me. | 13:02.11 |
| | Can you push them? My repo is in bits at the moment. | 13:02.26 |
| tor8 | sure. | 13:02.29 |
| | the search changes the behaviour a bit, now it's more in line with the other apps | 13:02.42 |
| | we now highlight all matches on a page at once | 13:02.50 |
| Robin_Watts | Do we have a 'current' one ? | 13:03.52 |
| tor8 | current what? page? search hit? behaviour? | 13:04.19 |
| Robin_Watts | i.e. if I search forward and find 3 occurences on a page, and then search forward again, does that move to the next page immediately ? | 13:04.24 |
| | or is there a current "search hit" ? | 13:04.37 |
| tor8 | search forward, 3 hits on a page, push 'n' to search and it starts searching the next page | 13:04.43 |
| | so it keeps track of 'have we searched this page before' (app->searchpage) | 13:05.04 |
| Robin_Watts | ok, so the only problem with that, is if we can't see all 3 hits on the visible region of the page at a time. | 13:05.11 |
| tor8 | yeah. if you're zoomed it's not ideal. | 13:05.23 |
| Robin_Watts | but that's an area we are deficient in anyway (we don't ensure that you can see the search results). | 13:05.47 |
| tor8 | we could rework the search interface to separate individual matches | 13:05.51 |
| Robin_Watts | On android, we zoom out. | 13:05.56 |
| | but that can wait for the GTK stuff. | 13:06.18 |
| tor8 | on most pages it should be pretty obvious to spot the hits, since the areas are inverted | 13:06.31 |
| henrys | Robin_Watts:anything to discuss about your customer or do I tell them pay now and we'll try a bit more to help you but no promises. I'm sort of in the dark here so I'm guessing a bit. | 13:45.22 |
| vtorri | tor8, in fz_link_dest struct, what is a "file specification" ? | 14:36.24 |
| Robin_Watts | vtorri: IIRC it's a const char *. | 14:38.42 |
| | and it's poorly defined, because it's poorly defined in the spec. | 14:39.10 |
| vtorri | it's a file name ? | 14:41.01 |
| Robin_Watts | vtorri: I think so. | 14:52.07 |
| vtorri | thank you | 14:52.44 |
| | about the GOTO(R) link, if I have correctly understood, the values lt and rb are not necessarly correct, and only the flags allow us to know which one is correct (i.e. specified in the pdf file). Am I right ? | 15:09.05 |
| Robin_Watts | vtorri: The flags allow you to know which ones are specified in the pdf file. | 15:10.43 |
| | I think we try to put "sensible" values in the undefined ones where possible. | 15:10.59 |
| vtorri | that's a bit weird | 15:11.18 |
| | then, should I really hve to take into account those flags ? | 15:11.30 |
| Robin_Watts | vtorri: You should really take those flags into account, yes. | 15:12.01 |
| | but we do our best so that if you don't, you should hopefully get sanish results. | 15:12.18 |
| vtorri | is there an example somewhere ? | 15:12.28 |
| Robin_Watts | nope. | 15:12.41 |
| vtorri | :/ | 15:13.07 |
| | so i don't see how to use them... | 15:14.55 |
| Robin_Watts | vtorri: No one has used them so far. | 15:16.27 |
| | Our example apps only go to pages, not to regions of pages. | 15:16.52 |
| vtorri | so my lib would be the first one ? :) | 15:17.33 |
| Robin_Watts | indeed. | 15:17.44 |
| vtorri | when I think it is finish, i really like that you (the devs) review my code so that it's the best possible | 15:18.16 |
| Robin_Watts | marcosw_: Hey. | 15:25.32 |
| | Then OpenJPEG2 branch on my mupdf repo on casper has, we believe, all the fixes in required to solve the openjpeg2 crashes with the fuzzing files from customer 395. | 15:26.59 |
| vtorri | beware, the openjpeg devs are not that good | 15:28.04 |
| | sadly, they are doing sometimes bad stuff | 15:28.18 |
| Robin_Watts | Could you rerun the fuzzing files with mupdf built from that branch? I hope we should get a clean bill of health. | 15:28.43 |
| | (and if we don't, it will let us figure out what to do next). | 15:29.15 |
| | vtorri: mmm. | 15:29.25 |
| vtorri | example: i was involved in that project. the guys were using winsock2 API, but when they were including winsock2.h, there wre compilmation errors. They have remarked that including winsock.h (the one for API 1) no error. | 15:30.15 |
| | i modified the code so that winsock2.h were included and told them that they were hiding a bug | 15:30.52 |
| | they reverted my code saying that the release were close, so "let's stay with winsock.h" | 15:31.41 |
| | i leaved that project just after that | 15:31.52 |
| | they did,'t even try to find the problem... | 15:32.32 |
| | didn't* | 15:32.36 |
| marcosw_ | Robin_Watts: what's up? | 16:20.34 |
| Robin_Watts | marcosw_: I was going to ask you to rerun the mupdf fuzzing tests. | 16:21.10 |
| | In fact, I did ask you that above. | 16:21.16 |
| marcosw_ | yeah, just reading the messages | 16:21.32 |
| Robin_Watts | but zeniko just came up with another couple of fixes. | 16:21.33 |
| | so I'm incorporating those now | 16:21.41 |
| marcosw_ | I'm rerunning the gs fuzzing with the valgrind enable and pacify options now. that will be done tonight. | 16:22.10 |
| spDuchamp | Anyone here ever use the openFrameworks ofxPDF (uses MuPDF lib) on a Raspberry Pi? | 16:23.06 |
| Robin_Watts | spDuchamp: I suspect not. I'm the only mupdf that has a Raspberry Pi AFAIK, and mine hasn't been powered on :( | 16:23.58 |
| | s/mupdf/mupdf dev/ | 16:24.05 |
| spDuchamp | Everything seems to be working fine, except that I can't render PDFs with images, so now I'm trying to pull stuff in from MuPDF into the ofxPDF libs folder and I'm having a heck of a time with it. Oh well, I'll keep banging my head on it. | 16:26.44 |
| Robin_Watts | spDuchamp: What version of mupdf is the framework based on? | 16:29.05 |
| | What happens with the stock version? Are images just missing? | 16:30.02 |
| spDuchamp | I'm not exactly sure what version. (https://github.com/satoruhiga/ofxPDF) | 16:31.30 |
| | I can display a test pdf that is all vector, but a PDF with embedded images doesn't render. | 16:32.14 |
| | The ofxPDF doesn't include the supporting libs. | 16:32.44 |
| Robin_Watts | spDuchamp: Right. They've stripped out jpeg support. | 16:33.28 |
| | bonkers. | 16:33.31 |
| | What's the benefit of using the framework over just using mupdf direct ? | 16:33.55 |
| spDuchamp | I've pulled out the mupdf/lib folder out of ofxPDF and I'm trying to put muPDF in. It's a slog. | 16:34.01 |
| | Well, I don't want to run X11. | 16:34.12 |
| Robin_Watts | spDuchamp: Nor do I :) | 16:34.25 |
| spDuchamp | I figured using oF would be an easy way for me to code the viewer I'm trying to build. | 16:35.02 |
| Robin_Watts | stock mupdf is a set of core libraries, written in portable C that work on pretty much every OS. | 16:35.11 |
| | We then have thin layers of code that build those libs into various example projects, including command line renderers, viewers for linux/macos/windows/ios/android etc. | 16:35.56 |
| spDuchamp | Well, I was able to compile stock mupdf on the Rpi. That works. But I'm not sure how that helps me display. I get a cannot open display error. | 16:38.21 |
| kens | goodnight everyone | 16:38.23 |
| Robin_Watts | spDuchamp: Right, so you've built the X11 version. | 16:38.55 |
| spDuchamp | ah. | 16:39.05 |
| Robin_Watts | If you're using some other windowing system, then you'll need to change the code. | 16:39.15 |
| | What windowing system are you using ? | 16:39.29 |
| spDuchamp | I'm hoping to not use any windowing system. That's why I was using openFrameworks. It lets my render direct to the HDMI port on the Rpi. | 16:40.08 |
| Robin_Watts | spDuchamp: Right. | 16:44.43 |
| | so you're rendering direct to a framebuffer. | 16:45.04 |
| | You'd have to write code to do that. | 16:45.18 |
| | I have no idea why they've stripped images out of the mupdf stuff. | 16:45.36 |
| | Either you'll have to reintroduce it, or you'll have to start from stock mupdf, and write a viewer that renders to the framebuffer. | 16:46.19 |
| | marcosw_: I believe everything is up to date for a rerun now. Want me to put details in a mail? | 16:47.10 |
| spDuchamp | Yeah, I'm going to have to figure out what stuff to bring back in from mupdf into the ofxPDF lib folder. | 16:47.19 |
| marcosw_ | Robin_Watts: I won't be able to start the mupdf/fuzzing tests until the gs/fuzzing test is down in about 12 hours, so an email would be a good reminder for me. | 16:47.55 |
| Robin_Watts | spDuchamp: Why not just step back to 5064894354e891653f4ee31684e7651380f61c99 before the jpeg stuff was stripped out? | 16:50.03 |
| | marcosw_: Sure. Thanks. | 16:50.15 |
| spDuchamp | Good idea. I'll give that a whirl. | 16:52.18 |
| Robin_Watts | henrys: Do we have any clever way of getting the CLA done electronically? | 16:53.51 |
| | i.e. can people print it out, sign it, scan it, email it ? | 16:54.07 |
| | ah, it says it can. Fab. | 16:58.56 |
| | henrys: You here? | 18:16.34 |
| | monxalo: Aha! | 18:17.21 |
| monxalo | Hello there :) | 18:17.30 |
| Robin_Watts | paulgardiner: ping ? | 18:17.35 |
| | monxalo: I suspect we've missed paulgardiner for the night, but he had some questions about your patch. | 18:18.02 |
| | let me try and remember them :) | 18:18.12 |
| | So, the first bit of your patch moves the background off the layout and onto the app style, right? | 18:18.57 |
| monxalo | sure :), he can also drop them at the bug page | 18:19.13 |
| | Correct. | 18:19.22 |
| Robin_Watts | monxalo: I think he was planning to, but had to head out before he could do it today. | 18:19.34 |
| monxalo | and the style is applied, for now, only to the MuPDFActivity. | 18:19.53 |
| Robin_Watts | How does that help overall? | 18:20.13 |
| | Does it help because android can now spot that it doesn't need to redraw the background under other 'solid' elements ? | 18:20.51 |
| monxalo | Well, Android applies a default background, base on theme selected. | 18:21.14 |
| Robin_Watts | monxalo: Ah, so the benefit is that it no longer needs to draw that default background, just our one ? | 18:21.46 |
| monxalo | exactly | 18:21.51 |
| Robin_Watts | OK, thanks. | 18:21.58 |
| | So, second part of the patch... | 18:22.03 |
| monxalo | That's what the android:windowBackground is for. | 18:22.20 |
| Robin_Watts | You set the views between having a background color, and not having a background color. | 18:22.40 |
| | Basically, when we have a bitmap, there is no point in painting the area white and then putting the bitmap on top. | 18:22.57 |
| | That makes sense to me. | 18:23.01 |
| | but I have a technical question... | 18:23.10 |
| | setBackgroundColor(BACKGROUND_COLOR): | 18:23.18 |
| | is BACKGROUND_COLOR an Android specific constant ? | 18:23.33 |
| monxalo | No, that is constant defined on the PageView class. | 18:24.02 |
| | But there is a constant in Android for white. | 18:24.15 |
| Robin_Watts | perfect. I wanted to be sure we were guaranteed it was white. | 18:25.07 |
| | and if it's our own constant it guarantees that. | 18:25.16 |
| | So, the patch looks perfect. | 18:25.37 |
| | Can we get a signed CLA from you? | 18:25.49 |
| | please | 18:25.52 |
| monxalo | If you're decided to use always white you can use Color.WHITE. | 18:26.17 |
| | I already did and send it to Miles. :) | 18:26.31 |
| Robin_Watts | monxalo: Awesome! Thanks. | 18:26.44 |
| SpNg | can ghostscript 9.07 convert from .eps to .svg? I was using an older version 8.7 yesterday and using sDEVICE=svg worked fine. On upgrade I'm getting 0 byte output files | 18:26.55 |
| Robin_Watts | monxalo: This has been a great help to us. | 18:27.20 |
| monxalo | No problem, happy to help :). | 18:27.50 |
| Robin_Watts | monxalo: Are you intending to work with MuPDF more ? | 18:28.09 |
| | oh, you're writing a viewer app, right? | 18:28.26 |
| Robin_Watts | has to run away for 10 mins. bbs. | 18:28.49 |
| monxalo | Yes, i am currently working adding some extra functionalities. | 18:30.06 |
| | Like trying to have a 2 page view, mainly for tablets landscape mode. | 18:30.50 |
| Robin_Watts | monxalo: Ah, cool. | 18:39.34 |
| | We've had requests for that. | 18:39.53 |
| | That should be achievable just with changes in the android specific code. | 18:40.17 |
| monxalo | Yes, i'm just trying to implement an Adapter and try to reuse most of the existing classes. | 18:41.19 |
| | One question, build related, is it possible to reduce mupdf library size on android, or it needs all dependencies? | 18:42.20 |
| | For me the file is 8 MB long, and it seems a bit big to just use rendering functions. | 18:43.07 |
| Robin_Watts | monxalo: There are a couple of factors. | 18:44.06 |
| | Firstly, by default we build both armeabi and armeabi-v7a. | 18:44.26 |
| | If you only build for one of them you halve the size of the apk. | 18:44.40 |
| | Secondly, we optionally include v8 to handle the javascript needs for the form filling - that's 1.5Meg or so there. | 18:45.11 |
| | A lot of the rest is the default fallback font we use, DroidSansFallback.ttf | 18:45.45 |
| | That may be on your device already. | 18:45.55 |
| | More of the datasize is taken by the CMAPs. | 18:46.14 |
| | You could reduce the number of CMAPs you include, but that would hurt you with cjkv support. | 18:46.48 |
| | The actual interpretation/rendering code is as compact as we can make it. | 18:47.10 |
| monxalo | Humm, so maybe i can have one apk for Arm v7 and one for plain Arm. | 18:47.50 |
| Robin_Watts | monxalo: That's what I do now. | 18:48.01 |
| monxalo | The current apk published on the Google Play Store, is it the armeabi or armeabi-v7a ? | 18:49.36 |
| Robin_Watts | monxalo: both. | 18:49.56 |
| | I publish 2 apks. The armeabi one is version N. The armeabi-v7a is N+1 | 18:50.21 |
| unverbraucht | Hi all | 18:50.40 |
| Robin_Watts | That way if a phone is capable of armeabi-v7a it gets the faster one. | 18:50.41 |
| unverbraucht | Robin_Watts: I'm the guy working on the armeabi compile of v8 | 18:50.57 |
| Robin_Watts | unverbraucht: Ah, hi! | 18:51.08 |
| unverbraucht | http://bugs.ghostscript.com/show_bug.cgi?id=693857 <- this bug | 18:51.13 |
| | Hey :) | 18:51.17 |
| | I've managed to run your version of v8 on a HTC dream (t-mobile G1) | 18:51.32 |
| | So I've got the armeabi build running | 18:51.40 |
| monxalo | I didn't know Google Play store supports multiple apks with dif architecture. | 18:51.42 |
| Robin_Watts | unverbraucht: brilliant. | 18:51.49 |
| | monxalo: It's a new(ish) feature. | 18:51.57 |
| unverbraucht | Then I remembered why it wouldn't work on the emulator | 18:51.57 |
| | The pre-honeycomb emulators pretend to have an FPU, but actually they don't | 18:52.13 |
| monxalo | Great to know. :) | 18:52.18 |
| unverbraucht | V8 checks this during runtime, creates VFP statements and hence the SIGILL | 18:52.29 |
| Robin_Watts | unverbraucht: Ah. Is there any way to stop V8 doing that ? | 18:52.52 |
| unverbraucht | So the library will work on actual devices, but you can't use the emulator to test it :/ | 18:52.57 |
| | I'm not really sure. It may be possible to compile it without any sort of FPU support at all. | 18:53.19 |
| | I haven't managed to do so yet though | 18:53.30 |
| | On the other hand you'd probably loose a ton of performance on most devices | 18:53.44 |
| | There are quite a lot of armv6 devices out there with an FPU | 18:53.55 |
| | afaik the only official devices without FPU where the G1 and the magic | 18:54.18 |
| | Both very very rare these days | 18:54.36 |
| Robin_Watts | unverbraucht: OK. That makes a lot of sense. | 18:54.38 |
| unverbraucht | Most of my armv6 devices have one. I tried various older Samsung phones like the Apollo or the 5700 | 18:55.02 |
| | So I'd go with the autodetecting library if possible | 18:55.17 |
| Robin_Watts | unverbraucht: yeah. It's just a pain that we can test in the emulator :( | 18:55.38 |
| unverbraucht | Yes, its annoying. | 18:55.47 |
| Robin_Watts | s/can/can't/ | 18:55.47 |
| | I wonder if there is a way to detect that we're in the emulator, and to update the v8 detection code to avoid the FP stuff in that case. | 18:56.31 |
| unverbraucht | I'll look into it | 19:00.52 |
| Robin_Watts | Thanks. | 19:02.42 |
| unverbraucht | Can I drop you a library somehow so you can test it? | 19:04.32 |
| | I compiled one that seems to work in the emulator | 19:04.39 |
| | Would dropbox be ok? | 19:04.44 |
| Robin_Watts | unverbraucht: Wow. That was fast. | 19:04.51 |
| | dropbox would be fine, yeah. | 19:05.12 |
| unverbraucht | Yeah I got this shiny new laptop from work a few days back | 19:05.15 |
| | Compiling has been pure joy since :D | 19:05.21 |
| | Ok | 19:05.23 |
| Robin_Watts | How does it work? Does it nobble the detection to always fail? Or are you spotting the emulator? | 19:05.41 |
| unverbraucht | I've built a version with hardwired softfloat | 19:06.48 |
| | Apparently it doesn't try to detect it then. | 19:07.04 |
| | I'm trying to build one now with patched autodetection | 19:07.22 |
| | But at first glance it looks as if its only trying to autodetect vfp3, which these old devices don't have anyway | 19:07.43 |
| | Maybe it was in later v8 versions where they added the autodetection | 19:07.55 |
| Robin_Watts | We only use a fraction of v8's power - its used for validating form fields. | 19:08.33 |
| | I'd expect that heavy maths being done inside a pdf would be very rare. | 19:08.48 |
| unverbraucht | So maybe this would be ok then | 19:09.02 |
| | I sent you the dropbox folder invitation | 19:09.09 |
| Robin_Watts | I have the soft one. | 19:10.56 |
| unverbraucht | Ok my bad, if compiled with softfp it also bails out on the G1. So if you want it to run on these older armv6 devices too you can't rely on the autodetection | 19:11.11 |
| Robin_Watts | so the soft lib works in the emulator? | 19:11.53 |
| unverbraucht | So the version you have is the one that runs on all armv6 devices including the emulator, | 19:11.55 |
| | Yes | 19:12.02 |
| Robin_Watts | Right. So I am tempted to use that as my armeabi lib. | 19:12.28 |
| | If I use the soft one for all armeabi devices and the standard one for armeabi-v7a we should work on every device, and the emulator, right? | 19:13.30 |
| unverbraucht | Yes, that should do the trick | 19:14.27 |
| | That's the setup I use in my app | 19:14.37 |
| | Oh and x86, if you want to support that | 19:14.51 |
| | There are a few x86 android devices out there these days | 19:15.07 |
| Robin_Watts | having an x86 lib would be nice | 19:15.23 |
| unverbraucht | I don't know how easy it will be to compile it with the older v8 though | 19:15.31 |
| | Is it at all possible to use a newer one? I think 3.12 would already bring x86 | 19:15.45 |
| Robin_Watts | As long as I can get a consistent set of libs out for all our platforms, I'd be happy to move to a more recent one. | 19:16.29 |
| unverbraucht | I'll try with your codebase, it seems like the titanium build script supports it | 19:17.00 |
| Robin_Watts | windows{32,64}/linux{32,64}/macos{32,64}/android | 19:17.01 |
| | unverbraucht: OK, thanks. | 19:17.12 |
| unverbraucht | That would be gingerbread and up then though | 19:17.13 |
| | np | 19:17.48 |
| Robin_Watts | What would be gingerbread and up then? | 19:19.27 |
| unverbraucht | The library. I needed to compile it against the gingerbread ndk | 19:19.39 |
| Robin_Watts | oh, for x86? | 19:19.59 |
| unverbraucht | I don't know if you can link it against a froyo target. | 19:20.02 |
| | Yes, thats for x86 only | 19:20.06 |
| | There was no x86 option for the froyo ndk | 19:20.17 |
| | Ha, works :) | 19:20.22 |
| Robin_Watts | That's fine. I'm not sure there are any x86 devices for froyo :) | 19:20.26 |
| unverbraucht | I hope not :) | 19:20.59 |
| Robin_Watts | unverbraucht: Brilliant. Can I get build instructions (and any code changes) for how to make our codebase build these libs please? | 19:21.07 |
| unverbraucht | I copied it into the dropbox folder | 19:21.07 |
| | Sure | 19:21.14 |
| | Should I attach that to the ticket? | 19:21.35 |
| Robin_Watts | That would be ideal. | 19:21.44 |
| unverbraucht | Ok, its there | 19:27.18 |
| | I used the titanium build scripts out of laziness and because I don't know how to build v8 with scons, but the scripts don't do all that much apart from creating a small NDK buildroot, setting a few environment vars and then running scons | 19:28.57 |
| | I didn't need to touch the v8 source at all, which is good | 19:29.09 |
| | In the newer revision of v8 we had to change some things in the gyp files to get a non-fpu version | 19:29.30 |
| | Robin_Watts: I'll be afk. If the instructions contain errors or omissions send me an email please or reply in the ticket | 19:31.17 |
| Robin_Watts | Thanks. | 19:31.39 |
| unverbraucht | Oh and please let me know how well the library works :) | 19:31.46 |
| | You're welcome | 19:31.50 |
| Robin_Watts | I will try it out tomorrow. It's 8:30pm here, so I'm almost done for the day. | 19:32.03 |
| unverbraucht | Ouch, then you're nearly on my timezone | 19:32.17 |
| | And nearly as late still at work ;) | 19:32.27 |
| | See you | 19:33.28 |
| Robin_Watts | tor8 or paulgardiner: Android overdraw review on robin/master | 19:50.24 |
| | mvrhel_laptop: Are you here? | 19:51.59 |
| tor8 | Robin_Watts: git should handle top-bit-set chars just fine if you use utf-8 | 19:54.56 |
| Robin_Watts | tor8: I tried it before, it caused problems. | 19:55.13 |
| | therefore I avoid it. | 19:55.18 |
| tor8 | might've been your editor assuming latin-1 ... that's usually the case | 19:56.12 |
| | anyway, patch looks fine | 19:56.25 |
| Robin_Watts | tor8: Ta | 19:56.32 |
| tor8 | will have to test tomorrow, now it's time for some star trek movies | 19:56.44 |
| Robin_Watts | tor8: which ones? | 19:58.58 |
| monxalo | Robin_Watts, checked now your diff commit for the overdraw patch, there's a fault for the setBackgroundColor(). | 20:04.32 |
| Robin_Watts | monxalo: What did I mess up? | 20:04.45 |
| | Color.TRANSPARENT ? | 20:05.00 |
| monxalo | yeap :) | 20:05.05 |
| Robin_Watts | will fix, thanks. | 20:05.13 |
| monxalo | and the call to setBackgroundColor should be after invalidate. | 20:05.21 |
| Robin_Watts | should it ? | 20:05.36 |
| | Doesn't the call to invalidate kick off a redraw? | 20:05.58 |
| | surely we'd want the background to be gone before we do that ? | 20:06.16 |
| monxalo | i think so because invalidate forces the view to redraw itself, and calling that after changing the background to transparent there might be some flickering. | 20:06.59 |
| | Placing the setBackgroundColor after assures that there already is content on the page before removing that layer :). | 20:07.42 |
| Robin_Watts | monxalo: It also ensures that we will overdraw at least once, surely? | 20:08.06 |
| | If we remove the background the worse thing that can happen is that that causes a redraw, right? | 20:09.09 |
| | which is exactly what invalidate() would do. | 20:09.17 |
| monxalo | Yes, but removing the background, i think it will call a invalidate again, but i can test this out. | 20:09.28 |
| Robin_Watts | If removing the background calls invalidate, then we should remove the invalidate call, right ? | 20:09.51 |
| monxalo | Right, i didn't thought about that. | 20:11.32 |
| | After checking the source code for the setBackgroundColor(), it does invalidate. | 20:13.50 |
| | so, steps are: remove call to invalidate, change setBackgroundColor(Color.TRANSPARENT). | 20:14.35 |
| Robin_Watts | fab. | 20:16.06 |
| | Does this mean that the other calls to setBackgroundColor should be tweaked too ? | 20:16.30 |
| monxalo | Hum, i think it's fine like this. | 20:18.55 |
| | If i can think of better tweaks, i'll submit them. :) | 20:19.43 |
| | I was thinking if there was a way to remove the overdraw of the page thumb and the hq patch. | 20:20.39 |
| | As for the cedilha, no problem, i just use utf-8 for everything. :) | 20:23.40 |
| Robin_Watts | monxalo: Patch updated. | 20:29.38 |
| Robin_Watts | will test it tomorrow. time to go cook! night all. | 20:29.58 |
| monxalo | See ya | 20:30.13 |
| tor8 | Robin_Watts: the originals. going through them all again. | 21:53.19 |
| | the new jj abrams ones are so ubelievably bad... | 21:53.32 |
| | unbelievably | 21:53.38 |
| Robin_Watts | tor8: I liked the reboot. Haven't seen "Into Darkness" yet. | 23:16.19 |
| | Forward 1 day (to 2013/05/23)>>> | |
IRC Logs