| | <<<Back 1 day (to 2016/09/15) | 20160916 |
| sebras | tor8 Robin_Watts: small fix for fz_unpack_tile() on sebras/master | 07:40.40 |
| | I stumbled upon this while looking into the TIFF-files produced by the luratech decoder. | 07:41.02 |
| Robin_Watts | sebras: Might be clearer to say that it'll skip a single extra component. | 08:53.08 |
| | but other than that, lgtm. | 08:53.14 |
| | I have a vague plan to replace fz_unpack_tile with a stream that does the unpacking. | 08:53.45 |
| | would save lots of memory. | 08:54.01 |
| sebras | Robin_Watts: why single extra component? b += n - dst->n will indeed skip all of them, no..? | 09:09.19 |
| Robin_Watts | sebras: Ah. | 09:14.06 |
| | Why not: skip = b - dst->n then ? | 09:14.14 |
| | then b += skip; | 09:14.18 |
| | I was confused by the if (dst < n) skip = 1; | 09:14.39 |
| | I was reading skip as "the number of bytes to skip" | 09:14.55 |
| | b += n - dst->n; suffers from aliasing problems. | 09:15.16 |
| | (or at least it might do - might be saved by the restrict stuff) | 09:15.55 |
| | because we write to memory pointers each time around the loop, some compilers will assume that dst->n may have changed. | 09:16.41 |
| | restrict *should* save it, but that depends on the compiler. | 09:16.57 |
| sebras | Robin_Watts: ah, ok. I didn't realize that. I'll make skip represent the number of components to skip. | 09:17.57 |
| | Robin_Watts: in that case I can actually do with b += skip instead of if (skip) b += skip | 09:19.01 |
| | because skip is normally zero | 09:19.12 |
| Robin_Watts | yeah. | 09:19.26 |
| | So... JNI_Onload doesn't appear to get called. | 09:38.59 |
| | and nor does the tls destructor. ass. | 09:39.18 |
| sebras | Robin_Watts: you mean JNI_OnUnload() right? | 09:39.40 |
| Robin_Watts | I do, sorry. | 09:40.05 |
| sebras | Robin_Watts: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html#JNI_OnUnload | 09:40.38 |
| | Robin_Watts: so... the class loader is never garbage collected? | 09:40.46 |
| Robin_Watts | Not according to my logging. | 09:41.26 |
| tor8 | sebras: Robin_Watts: I think it's the -i flag that throws off OSX sed | 09:46.57 |
| | -i needs an argument on osx | 09:47.28 |
| | sed -i .old -e '...' $(find ...) | 09:47.41 |
| sebras | tor8: ah. I was just chiming in with a suggestion, but I have no access to osx (as you know). | 09:48.35 |
| tor8 | that doesn't match the error message though, just something I remembered running into once | 09:49.06 |
| Robin_Watts | Hmm. | 09:56.10 |
| | If I run freds android app (which is based on the JNI), to load tiger.pdf, I see JNI_OnLoad called. | 09:56.41 |
| | If I then tell it to proof that file, I do NOT see JNI_OnLoad called a second time. | 09:57.09 |
| | and the proofing activity is invoked as a second activity using Intent. | 09:58.15 |
| | so I would have expected a new instance of the library to be started for that. | 09:58.35 |
| | If we are NOT getting a second instance of the library started, then we're sharing contexts. | 09:58.54 |
| sebras | Robin_Watts: tor8: updated version of fz_unpack_tile() on sebras/master that passes cluster (I forgot to fz_mini(n, dst->n) when looping over the components to actually extract. | 10:09.14 |
| | I can't step over n components and then skip over _another_ dst->n - n components. | 10:09.38 |
| | n - dst->n.... gah! | 10:09.46 |
| Robin_Watts | sebras: ooh, that's bad. | 10:10.20 |
| | using a function call as the upper bound on a for loop is very inefficient. | 10:10.43 |
| | cos it'll call that function every time around the loop. | 10:10.56 |
| sebras | Robin_Watts: I thought fz_mini() was either a macro or at least inline. | 10:11.04 |
| Robin_Watts | except dst->n, as discussed before needs to be recalculated each time. | 10:11.33 |
| | int nc = fz_mini(n, dst->n); | 10:11.51 |
| | and then k < nc | 10:11.56 |
| sebras | Robin_Watts: I'm opting to change the value of n when I set skip | 10:13.50 |
| | outside of any loops what so ever. | 10:13.59 |
| Robin_Watts | I can't see n ever being changed. | 10:14.40 |
| | Ah, new version just arrived. | 10:14.57 |
| sebras | runs in cluster as we type. | 10:15.14 |
| Robin_Watts | n -= skip; would have done, I think ? | 10:15.52 |
| | or n=dst->n; | 10:16.25 |
| | but yes, looks good now. | 10:16.53 |
| | This JNI thing is a pain. | 10:18.29 |
| | If we are really sharing a single lib instance across all activities that use it, then any memory corruption will affect all instances, not just one. | 10:19.38 |
| sebras_ | Robin_Watts: ok. n = dst->n;-version on sebras/master | 10:23.41 |
| | it clusters. | 10:23.48 |
| Robin_Watts | sebras: Looks ideal to me. Ta. | 10:24.55 |
| | although really for speed we should make all the loops count down :) | 10:25.16 |
| sebras_ | Robin_Watts: that you will fix with the new stream approach... ;) | 10:25.43 |
| Robin_Watts | sebras: yeah, whenever I get around to it. | 10:25.56 |
| | I did that approach when I moved the mupdf tiff decoders into SOT. | 10:26.10 |
| sebras_ | Robin_Watts: I'm trying to focus on evaluating the luratech drop, but I had issues with having mupdf render the TIFF files it produced. | 10:26.33 |
| Robin_Watts | sebras: If my investigations into JNI are to be believed, then: | 10:27.22 |
| | 1) We can't rely on JNI_OnUnload. | 10:27.32 |
| | 2) We can't rely on getting a lib instance per activity | 10:27.48 |
| | 3) We can't rely on thread closedown. | 10:28.04 |
| | That means we need a different way of cleaning up at the end of each activity. | 10:28.50 |
| jogux | Is this the "android sometimes just kills the process instead of gracefully cleaning up" issue? | 10:30.07 |
| Robin_Watts | jogux: I don't believe so - though that is also a potential issue. | 10:30.30 |
| | We have the deletion of the gprf files triggered by cleanup happening. | 10:30.52 |
| | If android is going to kill processes then that is going to cause us problems. | 10:31.15 |
| | Fred has a workaround in at the moment that will at least solve that. | 10:31.31 |
| sebras | Robin_Watts: can we transferdata gs<->mupdf without using files? | 10:32.47 |
| Robin_Watts | sebras: only by rewriting the gproof device in gs, I think. | 10:34.01 |
| | and life is too short for that. | 10:34.11 |
| | 3) is a pain. Every time we get called on a new thread, we clone the context. | 10:34.38 |
| | If the thread doesn't call us when it closes down, we can never bin that context, hence we'll never tidy up nicely. | 10:35.05 |
| jogux | the options I could see the file: 1) cleanup files in onStop. 2) do the 'delete files but keep a handle around so they still exist' trick. 3) stick them in a temporary folder and clean on startup too. | 10:35.24 |
| | "the options I could see for the files", I mean. | 10:35.37 |
| Robin_Watts | jogux: Currently fred deletes the files on the activity finish() call. | 10:36.00 |
| | which I guess won't get called if the activity just gets killed? | 10:36.12 |
| | The files are just one instance of the problem. | 10:36.28 |
| jogux | I think so. | 10:36.44 |
| | well we don't care about nicely cleaning up the context if the process is killed, right? | 10:36.57 |
| Robin_Watts | fred suggested yesterday that we have the stuff in the store tagged by document, so that when we close a document we can bin everything from it from the store. | 10:37.13 |
| | jogux: Cleaning up the context -> cleaning the store -> dropping the images -> dropping the file references -> deleting the files :) | 10:37.48 |
| jogux | :) | 10:38.01 |
| Robin_Watts | Currently everything else in the context is "just" leaked memory. | 10:38.14 |
| | currently. | 10:38.19 |
| sebras | Robin_Watts: https://developer.android.com/images/activity_lifecycle.png seems like onStop() might not be called in all circumstances, no. only onPause(). | 10:38.49 |
| jogux | we have the same "process just gets killed" issue on iOS iirc. | 10:38.54 |
| Robin_Watts | But if the lib instance is kept over multiple activities, and one activity is killed, then the leaked memory from that process will continue infecting other processes. | 10:39.29 |
| jogux | the lib instance *isn't* in the process?! | 10:39.47 |
| Robin_Watts | jogux: I had assumed it was. I am now confused. | 10:40.14 |
| | Activity = Process, right? | 10:40.20 |
| jogux | no | 10:40.23 |
| | one process can have multiple activities | 10:40.30 |
| Robin_Watts | or are sub activities within the same process? | 10:40.33 |
| | Ah.... | 10:40.35 |
| | So that might explain that. | 10:40.39 |
| | That's not so bad. | 10:40.52 |
| jogux | you never get just one activity killed - the whole process goes. | 10:41.04 |
| | if the process is still alive, an activity to be discarded will be properly cleaned up if/when android deems to do so. | 10:41.36 |
| Robin_Watts | ok, so maybe I can put something on Document.destroy() to bin everything from the store that has to do with that Document. | 10:42.39 |
| jogux | the important thing is any user state is saved on "onPause()". temporary files it matters less really. | 10:42.47 |
| Robin_Watts | jogux: That, I think, is an app level issue, rather than a mupdf JNI issue, so I'm happy to ignore that one. | 10:43.39 |
| sebras | jogux: if we clean them up on startup then we need to make sure that no other instance of the app is running and using those temporary files. | 10:43.54 |
| | jogux: I'm not sure how multiple instances of a running process works now that android has this multitasking thing. | 10:44.12 |
| jogux | sebras: I /think/ all an activities for a given app package are in the same process /by default/. | 10:44.52 |
| Robin_Watts | jogux: Years ago, we had problems when mupdf used static variables. | 10:45.21 |
| jogux | (annoyingly that's configurable on a per-app basis though I think. this is where my android foo starts to weaken.) | 10:45.23 |
| Robin_Watts | You could start an instance of muPDF from the menu, then go back to say a filemanager and start another one from there, and everything would get very confused. | 10:46.12 |
| | Since we changed it to not use any globals (except for Memento), it works fine now. | 10:46.41 |
| jogux | Robin_Watts: I'm not sure why that is. Sounds vaguely like it could be inconsistent use of both a context and statics, but I really shouldn't guess given I have no relevant knowledge of the code. | 10:47.45 |
| Robin_Watts | jogux: That was because we didn't have a context at that point :) | 10:48.07 |
| jogux | :) | 10:48.14 |
| Robin_Watts | the context was the solution to that. | 10:48.21 |
| | i.e. we fixed it by not having globals. | 10:48.35 |
| jogux | the 're-entrance' stuff is definitely a massive pain to get perfect, even without globals. | 10:48.55 |
| | I shan't mention the name of the customer that totally didn't get it :) | 10:49.39 |
| sebras | Robin_Watts: https://developer.android.com/training/articles/perf-jni.html#native_libraries I think the last paragraph before "64-bit considerations" might be interesting. | 10:50.27 |
| | Robin_Watts: it seems to suggest that mupdf is loaded by the system class loader. | 10:50.43 |
| | Robin_Watts: which might explain why the class loader is never unloaded. | 10:51.02 |
| Robin_Watts | Yeah. | 10:51.40 |
| | I can see us cloning context (i.e. running on new threads). | 10:54.18 |
| | I can never see the deconstructor for those threads being called. | 10:54.28 |
| sebras | Robin_Watts: https://groups.google.com/forum/#!topic/android-ndk/sf56xVIySfI | 10:54.43 |
| Robin_Watts | OK, so that says "you'll never see JNI_OnUnload call. Do everything on onCreate(), onDestroy()." | 10:57.02 |
| | The problem with that, is that our design deliberately avoids passing a context around (in Java). | 10:57.39 |
| | We magically make the context behind the scenes and stash it in TLS. | 10:58.02 |
| | We could need to change to having explicit calls in OnCreate/OnDestroy to make/break the context. | 10:59.33 |
| | s/need to// | 10:59.42 |
| | We store the base_context in a static, cos I had been assuming 1 lib instance per activity. | 11:00.54 |
| sebras | Robin_Watts: I don't understand how you came to the conclusion that this is not the case though. | 11:01.28 |
| Robin_Watts | What is not the case ? | 11:01.38 |
| sebras | Robin_Watts: 1 lib == 1 app (which may have multiple activities) | 11:02.00 |
| Robin_Watts | I believe that 1 lib == 1 app. | 11:02.26 |
| | But I do not believe that 1 lib == 1 activity | 11:02.41 |
| jogux | I think I believe what Robin believes. | 11:03.08 |
| | what would be the advantage of having a lib per activity? | 11:03.32 |
| Robin_Watts | The case in point is the example of freds mupdf app. Start it up, load tiger.pdf. Then click the 'proof' button, and it starts another activity (from the same app) to view the proofed version of tiger.pdf | 11:04.00 |
| | jogux: In this example, not a huge difference. | 11:05.00 |
| | What happens if I use multitasking to have 2 instances of the app running (i.e. not one nested in the other). Do they share the same lib instance? | 11:05.48 |
| | brb. | 11:05.58 |
| jogux | Robin_Watts: My understanding would be that [by default at least] one app == one process => they share, yes. | 11:07.22 |
| | Robin_Watts: aiui the terminology, that case you have one app running, showing two activities. | 11:07.40 |
| sebras | https://developer.android.com/guide/components/processes-and-threads.html#Processes says: | 11:10.06 |
| | supports an android:process attribute that can specify a process in which that component should run. You can set this attribute so that each component runs in its own process or so that some components share a process while others do not. | 11:10.26 |
| | doesn't this suggest that we could manipulate some settings file somwehere so that we would get one process per activity? | 11:10.51 |
| jogux | sebras: Yes. | 11:11.24 |
| | sebras: I was very careful to say 'by default' :-) | 11:11.44 |
| Robin_Watts | OK. | 11:12.11 |
| sebras | jogux: :) I'm not arguing against you deliberatly, just trying to figure out if there is a solution. :) | 11:12.19 |
| Robin_Watts | Changing those flags will likely impact the designer of the app. | 11:13.30 |
| jogux | sebras: Ideally... yes, what Robin said. | 11:13.40 |
| Robin_Watts | If we assume that we stick with the default for now... | 11:13.45 |
| jogux | It would be ideal, especially for the "mupdf as an SDK" case that the JNI doesn't make any assumption about which threading model is in use. | 11:14.14 |
| Robin_Watts | Using TLS in the way we do currently implies 1 context per lib instance. | 11:14.22 |
| | and indeed having a single context across instances might be viewed as a good thing, as it means they all share a single cache - so memory usage by one activity is reduced if another needs the memory. | 11:15.26 |
| jogux | nods. | 11:15.50 |
| Robin_Watts | But it does mean we can't rely on the context being tidied up properly. | 11:15.53 |
| | So we should keep that in mind. | 11:16.05 |
| sebras | Robin_Watts: the only way I see it in that case is if onPause() is used to clean up the cache. | 11:16.20 |
| | store | 11:16.26 |
| Robin_Watts | If we had a document level 'bin everything from the store' on Document.destroy, i think we'd be OK. | 11:16.49 |
| | The fact that thread destruction doesn't clear cloned contexts is bad, cos we leak errors stacks for each one. | 11:17.15 |
| | Maybe they do get cleaned up, and I've just not seen it happen yet, cos the threads are kept in a pile for reuse or something. | 11:17.53 |
| | At any rate, it seems that I should look at a Document.destroy() triggerable cleanup thing. | 11:18.26 |
| sebras | Robin_Watts: when would Document.destroy() be called? and by whom? | 11:20.30 |
| Robin_Watts | Document.finalize(), sorry. | 11:20.55 |
| | so it's called whenever we finish with a Document (and the finalizers run). | 11:21.18 |
| | i.e. it should get called when the activity ends. | 11:21.40 |
| sebras | Robin_Watts: yes, but the finalizers may run at an arbitrary time later _after_ the document object is not longer referenced. | 11:21.45 |
| Robin_Watts | sebras: Yes. But finalizers are run if the system runs low on memory, so it will happen 'just in time'. | 11:22.22 |
| sebras | Robin_Watts: this is why you have to provoke it using System.gc(); System.runFinalizers(); in your testing code. | 11:22.22 |
| | I wonder if there is a case where finalizers are _not_ run. | 11:22.55 |
| Robin_Watts | finalizers are not run if android decides to kill your app. | 11:23.11 |
| | but then all the memory is reclaimed anyway then. | 11:23.22 |
| sebras | Robin_Watts: right. what about other resources that we might hang on to. like file descriptors. | 11:23.49 |
| Robin_Watts | file descriptors aren't a problem, cos they die anyway when the app is killed. | 11:24.14 |
| | the fact that files aren't deleted *is* a problem, but that's a problem anyway, hence we need the workaround of deleting files. | 11:24.43 |
| sebras | Robin_Watts: yeah, but consider the case where the document object is not referened but also not yet finalized. and we have lots of those in our process. will we run out of file descriptors? | 11:25.01 |
| Robin_Watts | presumably android is smart enough to run the finalizers in that case ? | 11:25.31 |
| | If not, we're screwed. | 11:25.38 |
| | but there isn't much else we can do, afaict. | 11:25.49 |
| sebras | Robin_Watts: I'd doubt that JVM keeps track of the number of open file descriptors that JNI code may have opened. | 11:26.30 |
| Robin_Watts | We could have a Document.destroy() call that would preempt the cleanup, so people could optionally call that. | 11:26.37 |
| | sebras: No indeed, but it might be smart enough that in the event that trying to open a file fails it triggers a finalize pass and then tries again? Akin to what we do with failed mallocs. | 11:27.22 |
| jogux | it would seem sensible that the activity's ondestroy somehow cleans up file descriptors. | 11:27.32 |
| Robin_Watts | I believe we use the destroy()/finalize() system elsewhere. | 11:27.49 |
| | jogux: Sure. The activity could Document.destroy() manually as an optional step. | 11:28.11 |
| sebras | jogux: yes, that seems reasonable. | 11:28.34 |
| jogux | nods. | 11:28.36 |
| Robin_Watts | ok, so we have a plan, I think. | 11:28.57 |
| | Thanks. | 11:29.04 |
| sebras | handling resource management in plain C is difficult enough, then abstracting that mess inside Java just makes it more difficult, and then layering Android as activity concept on top of that... no wonder manufacturers tack 6GByte on to the phone SoCs nowadays to relieve app developers from having to sort out that mess. :) | 11:31.24 |
| Robin_Watts | Urgh. fz_image's are independent of Document. | 11:32.26 |
| | and it's perfectly reasonable to want to use an fz_image from one Document in another Document (consider the case where you want to create new document using an fz_image from another). | 11:33.05 |
| | I guess in that case Document.destroy won't bin the images. | 11:33.22 |
| jogux | sebras: Seems like a pretty accurate evaluations of current state of the art, yes :-( | 11:35.23 |
| Robin_Watts | So the only things ever put into the store that are tied to a document are pdf objects. | 11:43.12 |
| | Ha! pdf_drop_document_imp already calls fz_empty_store(ctx); | 11:51.42 |
| | So that's harsher than it needs to be, but it'll be safe. | 11:51.55 |
| sebras | Robin_Watts: would that interfere with another activity relying on that something is cached in the store? | 11:52.28 |
| Robin_Watts | sebras: Yes. It could cause the other activity to be less efficient. | 11:52.58 |
| sebras | Robin_Watts: right and FZ_LOCK_ALLOC would save us from thinking that the object is valid and then the store is emptied..? | 11:54.11 |
| Robin_Watts | sebras: Yes, the worst that could happen is that we might load a second copy of an image or something. | 11:54.43 |
| sebras | Robin_Watts: ok, in that case I'm happy. :) | 11:54.59 |
| Robin_Watts | I've added a FIXME for now. | 11:55.00 |
| Robin_Watts | lunches | 11:56.21 |
| | tor8: ping | 12:42.28 |
| sebras | Robin_Watts: port 194: No route to host. | 12:45.00 |
| Robin_Watts | 4 packets sent, 100% lost. | 12:45.39 |
| tor8 | Connection timed out. | 12:45.55 |
| Robin_Watts | Hi tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=d0ba2ffcf208dfc9344c88d5c05ffe802f7923cc is my first run at the store stuff we talked about. | 12:46.42 |
| tor8 | yes, that looks okay to me. | 12:47.18 |
| Robin_Watts | tor8: fab, thanks. | 12:47.36 |
| tor8 | so, with fz_filter_store we could do a smarter eviction when pdf documents are closed | 12:47.50 |
| Robin_Watts | tor8: Yes. | 12:48.05 |
| tor8 | and only evict the entries that are for resources belonging to said document | 12:48.06 |
| Robin_Watts | ha. We already have a Document.destroy() call that calls the finalizer :) | 12:48.31 |
| | That can result in cases where the pointer is NULL for a non null java object though. How does that affect what sebras and I were talking about yesterday? | 12:49.09 |
| tor8 | Robin_Watts: oh! yes, that's a possible way to cause the JVM to crash. | 12:49.28 |
| Robin_Watts | tor8: The JNI code should be made to cope. | 12:49.49 |
| tor8 | yeah, I think checking and throwing NPEs there is going to be required :/ | 12:50.10 |
| | the user should be punished, but not by taking down the JVM | 12:50.29 |
| Robin_Watts | I agree. | 12:50.40 |
| | sebras: So for any class X in which we use the destroy/finalize pattern, the x = from_X(env, self); routine should check for the pointer being NULL and raise an exception, and then check for x == NULL and return. | 12:53.17 |
| sebras | Robin_Watts: can do, but I don't understand how this can happen (yet). | 12:55.05 |
| | why would the pointer argument be null? | 12:55.29 |
| Robin_Watts | sebras: suppose someone calls Document.destroy() and then continues to use the Document object. | 12:55.41 |
| | It's something they shouldn't do, but it's something they could do. | 12:56.55 |
| sebras | Robin_Watts: right, because destroy() can be called by someone who is not the JVM. | 13:00.26 |
| | ok. | 13:00.29 |
| | I'll create a commit. | 13:00.32 |
| Robin_Watts | sebras: Fab, thanks. | 13:01.48 |
| | Yeah, the point of destroy() is for someone other than the JVM to be able to force "effective" finalisation | 13:02.21 |
| tor8 | Robin_Watts: so, fred added a third party module to platform/java/src/kankan but no accompanying README or LICENSE or COPYING file. | 13:51.41 |
| | we should fix that ASAP | 13:51.54 |
| Robin_Watts | tor8: Crap. I missed that in my review entirely. | 13:52.39 |
| tor8 | it looks like about 70kb of java source for some wheel widget thingy | 13:53.18 |
| sebras | tor8: the license _is_ mentioned in the source files though. | 13:53.24 |
| Robin_Watts | yeah. | 13:53.38 |
| sebras | tor8: I attempted to check if the string kankan is used elsewhere but I cannot find it. | 13:53.52 |
| tor8 | my first question is ... do we really need a third party widget library? is this something that SO uses and we need it to match the GUI? | 13:54.08 |
| sebras | tor8: though I'm not sure if fred planned to use it in the future..? and I assumed that someone agreed already without me knowing. | 13:54.13 |
| tor8 | the line width dialog uses it | 13:54.42 |
| Robin_Watts | tor8: Yes, we want to exactly match the UI in SO. | 13:55.30 |
| | So I'd assume fred is planning to use it there too. | 13:55.42 |
| sebras | tor8: oh.. over in platform/android... | 13:56.03 |
| tor8 | Robin_Watts: well, then it should be in platform/android not in platform/java | 13:56.30 |
| Robin_Watts | tor8: Yes, I think I agree. | 13:56.50 |
| sebras | tor8: so shouldn't it be in platform/android in that case? or do we envision the platform/java viewer to use the same? | 13:56.56 |
| tor8 | platform/java should be the platform independent library only | 13:57.07 |
| Robin_Watts | (tor8: broadly. the mupdf_native.c stuff has android #ifdefs in it) | 13:58.21 |
| | but for java code, yes. | 13:58.32 |
| tor8 | Robin_Watts: yes | 13:59.30 |
| sebras | apparently it's from https://code.google.com/archive/p/android-wheel/ and has a number of unresolved issues reported https://code.google.com/archive/p/android-wheel/issues | 14:01.26 |
| tor8 | using a 70kb widget for picking a line width seems a bit overkill to me. there's got to be a reasonable native android widget that's got to be good enough for that purpose. | 14:04.45 |
| | googling around, it seems like the main reason d'etre for kankan is that iOS has a wheel picker and android doesn't. | 14:05.12 |
| sebras | tor8: I wonder what version is used, because the version on the google code site is not identicial to the one we have now. | 14:06.30 |
| pedro_mac | sebras: you can use a Spinner and have resources for each item in the list (or draw them on demand, if youâre bored) | 14:17.19 |
| sebras | tor8: ^^ | 14:17.37 |
| | pedro_mac: I have no ideas about that code, I just noticed that it appeared. :) | 14:17.55 |
| pedro_mac | or a Picker (more like the ui in SO) | 14:18.44 |
| | sebras: sure - itâs worth remembering that a lot of the SO android code was done when many of the ânewerâ features didnât exist | 14:19.28 |
| | (the legacy SO code emulating the functionality of the android UI controls) - I guess you guys are more interested in NUI equivalence though? | 14:20.45 |
| sebras | pedro_mac: to my limited knowledge about the this part of the project I'm guessing that this is the case. | 14:21.48 |
| pedro_mac | scrolls back and sees references to kankan and all becomes clear | 14:21.49 |
| | what is the minimum API for muPDF? | 14:27.29 |
| tor8 | pedro_mac: whatever we want it to be, I guess. | 14:28.15 |
| pedro_mac | I think NUI is API 16 | 14:28.20 |
| tor8 | the old viewer was API 8 or something really ancient | 14:28.39 |
| pedro_mac | Android Pickers have been available since API 11 (Honeycomb) and are equivalent | 14:28.42 |
| tor8 | but there's nothing holding us back from going with at least android 3 or 4, IMO | 14:29.06 |
| pedro_mac | tor8: great - if itâs android 3 then you could use the built-in Picker instead | 14:29.38 |
| sebras | tor8: pedro_mac: <uses-sdk android:minSdkVersion="8" android:targetSdkVersion="16"/> | 14:29.40 |
| | this is what we have in platform/android today. | 14:29.46 |
| pedro_mac | if you need to support API 8 (2.x) then youâd need kankan or similar | 14:30.08 |
| tor8 | I'm happy to require android 3 if it means fewer third party dependencies | 14:30.56 |
| sebras | pedro_mac: wait.. what?! so the deprecated the built-in Picker? | 14:32.18 |
| | pedro_mac: after API 7. | 14:32.30 |
| pedro_mac | tor8: cool. Spinner could work for older devices - itâs basically like a drop-down menu | 14:32.33 |
| | sebras: APIs before android 3 didnât have any âpickerâ controls (spinny lists), just a âSpinnerâ which is a drop-down list. Iâm assuming that we are using kankan just now so that we can do nice spinny wheels on older APIs. | 14:44.55 |
| sebras | pedro_mac: alright, now I get it. :) | 14:45.48 |
| pedro_mac | from API 11 there are various Pickers (Number, Date, Time) which look & behave more like kankan. I think the most straightforward method would be for us to implement a simple spinny wheel using a ListView. the âadded extrasâ are the centre item highlighting and restricting the list scrolling to stop at the centre item rather than top/bottom of the parent view | 14:47.58 |
| sebras | pedro_mac: https://developer.android.com/reference/android/support/v17/leanback/widget/picker/Picker.html and this one is available from API 17 onwards? | 14:52.45 |
| | pedro_mac: for most of the classes it states "Added in API level 8" in the upper right corner, but not for the Picker. | 14:53.32 |
| pedro_mac | sebras: mm, I hadnât noticed that Picker had only been added then; Iâm assuming that this was a later generalisation of the specific number/dat/time pickers | 14:56.08 |
| sebras | pedro_mac: indeed. {Date,Time}Picker were there since level 1. | 14:57.29 |
| Robin_Watts | There are issues with supporting older than API 16, I believe. | 15:03.30 |
| | Or is that for exes rather than .so's? | 15:04.12 |
| | Yeah, just exes I think. | 15:07.29 |
| | The old code was API 8 or 9 I think (multitouch came in with 8?) | 15:08.50 |
| sebras | Robin_Watts: tor8: a slew of JNI-cleanups on sebras/master ought to be easy to review. | 15:15.50 |
| Robin_Watts | sebras: Various things on robin/fred too if you are so inclined. | 15:16.11 |
| sebras | Robin_Watts: typo in f4d2933 instace -> instance | 15:18.33 |
| | Robin_Watts: how come you didn't get a wwarning for that one? | 15:18.39 |
| Robin_Watts | sebras: They all look good to me. | 15:18.43 |
| | sebras: Cos I'm still testing :) | 15:19.14 |
| sebras | Robin_Watts: also in the same commit, why declare gs_api_init_with_args() when it is not used? | 15:19.21 |
| | Robin_Watts: oh.. another typo! gs_api_init_with_args --> gsapi_init_with_args perhaps? | 15:19.50 |
| Robin_Watts | Ah, that commit. I have tested that, but not in the USE_GS_API case :) | 15:21.36 |
| | fixed locally, thanks. | 15:21.46 |
| tor8 | Robin_Watts: in pdf_filter_store, maybe the type should be pdf_document *doc = (...)doc_, so the == test has matching pointer types | 15:23.36 |
| Robin_Watts | tor8: yeah, the cluster spotted that, and I've just pushed a fixed commit. | 15:24.34 |
| | reclustering now. | 15:24.43 |
| sebras | Robin_Watts: I have another update for you. | 15:24.55 |
| Robin_Watts | sebras: It is used, but only if USE_GS_API is defined. | 15:25.09 |
| sebras | Robin_Watts: no.. please take the commit at the top of sebras/wip instead of the one you have on robin/fred | 15:26.15 |
| Robin_Watts | sebras: will look in just a mo. | 15:26.34 |
| sebras | Robin_Watts: I've added all the .java files I've added recently. | 15:26.35 |
| | Robin_Watts: if you're correcting the paths you might as well have the list complete. :) | 15:26.40 |
| Robin_Watts | Oh, cool. | 15:26.40 |
| | yeah, nice. | 15:26.45 |
| sebras | tor8: do you also want to LGTM sebras/master or is it sufficient with Robin's? | 15:29.05 |
| Robin_Watts | sebras: Your commit lgtm. | 15:30.44 |
| | tor8/sebras: Updated commits on robin/master. These test out on cluster and ndk-build. | 16:06.00 |
| tor8 | Robin_Watts: I'd remove gen = buf->i completely, replace with a comment /* ignore gen */ | 16:18.46 |
| Robin_Watts | tor8: could do. | 16:19.06 |
| sebras | Robin_Watts: gsapi_set_stdio returns int and only takes one void* in the beginning. | 16:22.37 |
| Robin_Watts | sebras: I've fixed that in the latest version have I not? | 16:22.58 |
| sebras | oh.. the second parameter is also supposed to be a function pointer. | 16:23.10 |
| | nope, sorry. :) | 16:23.16 |
| | you renamed the intefaces, but their argument are declared wrong (compared to the gs source) | 16:23.43 |
| | also const is missing | 16:23.46 |
| | and the return value from the function pointers should be int | 16:23.58 |
| | Robin_Watts: in the android context fixing you write "so we'll just here for now"... here what? :) | 16:27.40 |
| Robin_Watts | Ok, fixes up for those :) | 16:29.18 |
| | I didn't see a missing const? | 16:29.34 |
| sebras | Robin_Watts: tor8: I don't know about "Silence some warnings."... If we don't support these, and we have no immdiate plans to support it either; can't we just remove the code? | 16:30.12 |
| Robin_Watts | sebras: I'm in the process of hacking something together for it. | 16:30.34 |
| sebras | Robin_Watts: given that evict() is O(1) how come you claim O(N) instead of O(N^2) by basically just inlining evict()? | 16:37.08 |
| Robin_Watts | evict is not O(1) | 16:37.21 |
| sebras | why one? | 16:37.35 |
| | why not? | 16:37.40 |
| | where in evict() do we iterate the list of items in the store again? | 16:38.03 |
| Robin_Watts | OK, sorry, evict is O(1), but it involves dropping the lock and taking it again. | 16:38.23 |
| | hence any 'filter' based on calling evict can't be O(1) or even O(n) cos you have to restart the search after you evict. | 16:39.02 |
| sebras | Robin_Watts: aha! ok. that makes more sense. so the commit message was a bit misleading. :) | 16:39.09 |
| | Robin_Watts: oh.. now I see prev = store->tail.. ok. I get it! | 16:39.40 |
| | Robin_Watts: and I'm cool with the code as it is. | 16:39.55 |
| Robin_Watts | I'm comfortable with the commit message :) | 16:39.59 |
| sebras | Robin_Watts: I'm sure _you_ are, but am I? ;) | 16:40.24 |
| Robin_Watts | "Improve fz_filter_store speed" "Now linear time rather than n^2" | 16:40.52 |
| | What is wrong or unclear there ? | 16:41.08 |
| | or do I have the wrong commit message? | 16:41.37 |
| sebras | Robin_Watts: nothing wrong, but I still had to ask to figure it out. :) | 16:41.47 |
| | Robin_Watts: nvm, now that I understand it, it is not a problem. | 16:42.15 |
| Robin_Watts | ok :) | 16:42.20 |
| sebras | Robin_Watts: ok. I'm happy with everything below text-shaping. | 16:43.34 |
| Robin_Watts | sebras: Thanks. | 16:43.47 |
| sebras | Robin_Watts: np. | 16:45.14 |
| Robin_Watts | oh, crap. | 16:53.44 |
| | I pushed an old version to golden, not to origin :( | 16:53.57 |
| | Fixed. No one saw that, alright? | 16:59.01 |
| fredross-perry | Saw what? | 16:59.18 |
| sebras | who? | 17:03.45 |
| Robin_Watts | He's on first. | 17:04.01 |
| fredross-perry | what's in the jar? | 17:13.06 |
| | Forward 1 day (to 2016/09/17)>>> | |
IRC Logs
