[gs-bugs] [Bug 691756] speed up executing display lists through optional bounding

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Tue Feb 15 02:20:27 UTC 2011


http://bugs.ghostscript.com/show_bug.cgi?id=691756

--- Comment #1 from Daniel Dutkiewicz <dsdutkiewicz at msn.com> 2011-02-15 02:20:23 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

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the gs-bugs mailing list