| | <<<Back 1 day (to 2017/02/14) | 20170215 |
| sebras | tor8: there are a few patches for review on -nui:sebras/master all trivial stuff. | 14:16.30 |
| impulse | what was that feature called where you can smoothly scroll between pages? | 15:06.19 |
| sebras | impulse: you mean continous scrolling, where the next page usually appears immediately below the current page? | 15:07.15 |
| impulse | ah yes that's it | 15:07.25 |
| | thanks | 15:07.26 |
| | is that still a thing? i can't find any mention of it by grepping the source | 15:08.58 |
| sebras | impulse: I'm assuming we are talking about mupdf on android here..? | 15:09.33 |
| impulse | nope on desktop linux | 15:09.44 |
| sebras | impulse: the mupdf library doesn't care how the rendered pages are laid out in the GUI. | 15:11.08 |
| | impulse: the current mupdf android app has horisontal continuous scrolling. | 15:11.23 |
| | impulse: this proves that it can be done. | 15:11.33 |
| | impulse: but the mupdf-x11 and mupdf-gl viewers for desktop linux does not implement this. | 15:11.50 |
| impulse | oh ok. old versions did though, right? | 15:12.44 |
| sebras | impulse: I haven't heard of any plans from tor8 to implement this for mupdf-gl. | 15:12.50 |
| | impulse: no, not continus scrolling where you can see the bottom half of the previous page and the top half at the next page at the same time, no. | 15:13.35 |
| | impulse: but the mupdf android app has had this for a long time though. | 15:14.49 |
| impulse | oh ok | 15:15.16 |
| | is the android app dev in here? | 15:15.47 |
| sebras | impulse: yes. | 15:16.14 |
| | impulse: there are a few of us. | 15:16.53 |
| impulse | oh you work on it too? | 15:17.08 |
| | JNI. nice | 15:18.10 |
| malc_ | impulse: http://repo.or.cz/w/llpp.git | 15:28.25 |
| impulse | looks nice | 15:39.13 |
| chrisl | acharles: I meant to say yesterday: I commit a few fixes for the -dSAFER code, so it should be working better now | 15:47.14 |
| impulse | hmm in the old version of mupdf i was using, scrolling to the next page scrolled to the top of the next page | 15:48.27 |
| | oh smart_move_* works nicely | 15:58.57 |
| | tor8: what do you think about having 'j' jump to the next page when you reach the bottom? | 16:22.58 |
| tor8 | impulse: I think that's a bad idea. use the smart move keys if you want a continuous reading experience when zoomed in. | 16:30.04 |
| impulse | k | 16:30.15 |
| sebras | tor8: in your patch on tor/master how do the graphics operations performed by the fz_device end up on the Android.graphics.Bitmap? we supply &dummy to fz_new_pixmap_...(). hm... | 17:44.36 |
| | found it, in androidDrawDevice_lock()! that was well hidden! | 17:59.21 |
| | who knew that locking the device meant changing the samples pointer inside the pixmap!? :) | 18:00.39 |
| Robin_Watts | sebras: Urm... locking the device = "lock the underlying pixels in place". | 18:01.36 |
| | in java the bitmap can move around all the time. In order for it to be safe for us to write to, we need to stop it moving. | 18:02.15 |
| | And that means "locking" the Android bitmap. | 18:02.21 |
| | The code has always worked like that, I believe. | 18:02.29 |
| sebras | Robin_Watts: yeah, doesn't mean I understood it though. | 18:06.04 |
| | Robin_Watts: now I'm just puzzled by the coordinates, but the mechanism for drawing seems sane. | 18:06.27 |
| Robin_Watts | sebras: hehe. Coordinates are always confusing. | 18:06.54 |
| sebras | I guess this is more of matter of me understanding the code rather than actually reviewing it. | 18:07.04 |
| Robin_Watts | Took me ages to get the previous version working, and Tor couldn't understand it. | 18:07.13 |
| | This version should at least be easier cos we don't have to fudge stuff for the span these days. | 18:07.35 |
| sebras | I think fitz/android don't agree on where origo of the page is, because I see -pageX in there. | 18:10.08 |
| | I guess it is because we consider origo to be the lower left hand corner of the image, whereas android uses the upper lefthand corner, but I'm so confused now. | 18:11.20 |
| Robin_Watts | sebras: That would explain pageY, not pageX :) | 18:12.00 |
| sebras | ehm... see! confused! :) | 18:12.21 |
| Robin_Watts | sebras: The general problem is that we have a bitmap that represents a sub area of a page, and we need to redraw a small patch of that. | 18:13.00 |
| | So you've got 2 layers of nesting going on. | 18:13.15 |
| sebras | yeah, and the subarea is the patch. | 18:13.59 |
| | I got that much. | 18:14.01 |
| Robin_Watts | which subarea? | 18:14.18 |
| | Consider the case where we are zoomed into the page. | 18:14.41 |
| sebras | the last one. | 18:14.43 |
| Robin_Watts | The page is much larger than the bitmap we hold. | 18:14.54 |
| | then a widget on the page updates itself. | 18:15.08 |
| | we need to redraw just that tiny patch. | 18:15.24 |
| sebras | I don't think Android knows about the annotation widgets yet. I believe that this is used for rendering the, possibly zoomed in, page. | 18:16.56 |
| | but due to panning maybe android decides to only update a part of the full bitmap. | 18:17.25 |
| Robin_Watts | sebras: The old code was capable of coping with that case. | 18:17.26 |
| | I believe this new code is also capable of coping with it - if it isn't, that's a serious regression. | 18:17.45 |
| | Whether the app makes use of the ability to drive it in that way is a different question. | 18:18.08 |
| sebras | maybe it is, but I dont' understand this yet. | 18:18.15 |
| | I' | 18:18.25 |
| Robin_Watts | i.e. it's possible that the current app code only ever calls this to redraw complete bitmaps. | 18:18.52 |
| sebras | m looking at the nui app code and how it determines how to ask the AndroidDrawDevice what to draw. | 18:18.54 |
| Robin_Watts | I hope tor tested the other case. | 18:19.10 |
| | sebras: Ah, I can't help with that. | 18:19.15 |
| sebras | no, I should be the one helping with that... | 18:19.27 |
| | but I'm caught in a self-referential loop. | 18:19.37 |
| Robin_Watts | I wrote a test for the old style where it redrew a bitmap in "random" tiles or something. | 18:19.59 |
| | :) | 18:20.01 |
| sebras | Robin_Watts: at the moment I don't think the pdf annotations are actually hooked into the nui stuff. | 18:20.14 |
| Robin_Watts | I'm buried in cluster perl code | 18:20.18 |
| sebras | Robin_Watts: so there doesn't appear to be any annotation widgets to know about or to interact with. | 18:20.56 |
| Robin_Watts | sebras: Indeed. I mentioned the widgets merely as an example of why this might occur. | 18:21.21 |
| | (not necessarily now, but in the fullness of time) | 18:21.42 |
| sebras | ok, I need to know what local visible rectangle, global visible rectangle is and what getLocationOnScreen() actually returns in order to sort this out. | 18:22.50 |
| | I'll take a break now, happy that I understood the bitmap passing at least. | 18:23.12 |
| | biab. | 18:23.15 |
| | and thanks for helping out! | 18:23.21 |
| acharles | chrisl: Thanks, Iâll take a look | 20:47.51 |
| | Forward 1 day (to 2017/02/16)>>> | |
Log of #ghostscript at irc.freenode.net.