| Summary: | speed up executing display lists through optional bounding | ||
|---|---|---|---|
| Product: | MuPDF | Reporter: | zeniko |
| Component: | fitz | Assignee: | Tor Andersson <tor.andersson> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dsdutkiewicz |
| Priority: | P4 | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Customer: | Word Size: | --- | |
|
Description
zeniko
2010-11-07 18:07:22 UTC
awhile ago i thought that this was possible as it would allow drawing the display list to the screen in blocks (maybe even multicore rendering) i even have drawings of how it would work but i didn't know the details so i'm happy some one else was able to do it and i think this ability should be included in mupdf ---- the following are my notes on the process model of multicore renderering (it would be so cool if it really did reduce the rendering time but i think that image decompression and scaling are the time eaters): one key thing is that a tile map is a 2d array of pixel maps -- mupdf should use multiple rendering threads on multiple core -- this would start up a thread pool and then dispatch each tile as a job to the pool and then compose the results -- as the page data is read only to the threads and only the tile pixmap for that job is writable no locking is required except on the job queue -- the locking of the job queue prevents a job from being taken by more then one thread this needs a thread pool job queue (tpjq) that has a number of threads, a job queue and a results queue -- there are only 4 operations on a tpjq: create, destroy, add job, get result -- if the number of threads is 1 this is so when the threading is disabled the tpjq works the same interface wise but the jobs are only run when getting the results from the tpjq this is so that when adding the jobs they can all be added to the queue without it blocking -- to render the page you create the tpjq then you create and put all the jobs into it after that you wait for results and compose them into a table when all the jobs results are ready you destroy the tpjq -- in each thread it fetches a job does it and puts the results on the results queue -- each job has as inputs a page and a part both of which are read only to the job thread and outputs a pixmap the pixmap is allocated when the job is created -- having the page and part be read only to the job thread avoids needing to lock them but this requires that the page is fully loaded before render jobs are dispatched; anything that needs to be loaded from the page during rendering can't be used to update the page Fixed in commit fda7116fc12ea7e125ff8fc9851e3ca9280459b9. |