| | <<<Back 1 day (to 2020/04/11) | Fwd 1 day (to 2020/04/13)>>> | 20200412 |
| kammerer | > We don't do any other sort of synchronisation, because we don't believe we need to. | 12:49.56 |
| | Robin_Watts_, yes I'm totally agreed. But 'simultaneous' word in docs looks confusing: "No simultaneous calls to MuPDF in different threads are allowed to use the same context/document". In JVM world synchronization is required not only for non-simultaneous execution, but also ensures that all cached memory (in processor caches) are uptodate. But | 13:18.30 |
| | mupdf doc says nothing about last thing (maybe it's something self-evident in the native/c world) | 13:18.31 |
| | Looks like that Mupdf.drawPage is overssynchronzied, because page rendering is performed under lock after display list extraction | 13:20.52 |
| | What is penalty for intermediate step with display list compare to direct page rendering without it (in terms of performance/memory/time for example for heavy-weight pdf documents with large scanned pages)? | 13:25.26 |
| Robin_Watts_ | kammerer: For android, at least, we draw into a Bitmap. | 14:05.47 |
| | In order to be able to draw into an array of pixels, we need to lock the pixels so the JVM can't move it above. | 14:06.04 |
| | about. | 14:06.06 |
| | Accordingly we have to lock/draw/unlock. | 14:06.21 |
| | kammerer: display list construction/playback overhead is not huge. | 14:06.54 |
| | Images are inserted into the display list as references, so no bulk data copying is required. | 14:07.30 |
| kammerer | Robin_Watts_, "Images are inserted into the display list as references, so no bulk data copying is required." If I destroy page would display list still be valid? Would I get new image after page rereading and display list construction or it would be same object as referenced in first display list? | 14:22.22 |
| | So bitmap 'lock/unlock' implicitly triggers some kind of synchronization mechanism? | 14:24.45 |
| Robin_Watts_ | If you destroy the page, the display list will still be valid. | 14:25.26 |
| | Images from within the page will be kept alive by the references from the display list. | 14:25.43 |
| | If you reread the page you should get the same image reference back, yes. | 14:26.08 |
| | I can't remember the details on bitmap lock/unlock immediately. | 14:26.40 |
| kammerer | NB: As I see there are a lot of 'synchronized' function in MuPDFCore, but I'm interesting in raw synchronizations mechanism. You pointed that 'When you init mupdf, you pass in a set of lock/unlock functions' but MuPDFCore doesn't perform such thing | 14:37.52 |
| | <<<Back 1 day (to 2020/04/11) | Forward 1 day (to 2020/04/13)>>> | |
Log of #mupdf at irc.freenode.net.