| | <<<Back 1 day (to 2017/02/20) | 20170221 |
| Diemex | I'm just returning to an Android project that uses compiled mupdf binaries. I think it was version 1.7. Has anything happened that improves Android support? | 18:54.54 |
| Robin_Watts | Diemex: yes. | 19:48.32 |
| | We have "proper" JNI bindings now. | 19:48.40 |
| Diemex_ | Robin Watts: GREAT! I'll have to update then and try it out. | 21:00.47 |
| | Is there direct support for multithreading? I recall looking into it, but the code was rather complex hehe. | 21:01.50 |
| Robin_Watts | Diemex_: The core of MuPDF supports multithreading, yes. | 21:04.28 |
| | The JNI bindings should behave too. | 21:04.38 |
| Diemex_ | Is there support for rgb565 Bitmaps? With the old binaries I'm getting errors that it has to be argb888 | 21:13.57 |
| | Robin Watts: Is the information about the multithreading on the webpage still up to date? Do I still need to supply my own functions for locking etc? | 21:49.41 |
| | Would having one thread that loads pages and holds onto the Page objects and several threads that use these Page objects to render pages work? From how I understood it I just cant have multiple threads manipulating or interacting with the pdf? But all the information for rendering of the pages should be contained in the Page object, right? I open the document once. Load pages I need. Store the Page objects somewhere and just re | 21:59.41 |
| Robin_Watts | Diemex_: not 565, no. 8888 or 888 are possibilities now. | 23:53.41 |
| | The JNI interface handles all the locking for you. | 23:53.51 |
| | If you're calling at the C level, then you have to do your own. If you're calling at the java level then the locking is taken care of for you. | 23:54.17 |
| | Page objects do not contain all the information for a page. | 23:54.50 |
| | They contain stuff like the bbox and information for where in the file to get the page streams from. They don't contain the page stream itself. | 23:55.17 |
| | So when you use the page stream, you hit the file. That needs to be linearised, because only one thing can be accessing the file at once. | 23:55.44 |
| | That's handled by the JNI for you. | 23:55.53 |
| | BUT to be truly efficient you should plan for it. | 23:56.06 |
| | The best bet is to make displaylists in just one thread, and then use them in as many other threads as you need. | 23:56.34 |
| | Forward 1 day (to 2017/02/22)>>> | |
Log of #ghostscript at irc.freenode.net.