[Webkit-unassigned] [Bug 68353] [Qt] Apply ParalellJobs for ImageBuffer::platformTransformColorSpace method

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Oct 5 01:46:41 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=68353





--- Comment #21 from Andreas Kling <kling at webkit.org>  2011-10-05 01:46:41 PST ---
(In reply to comment #19)
> > Could you explain this to me?
> > Why is this better than deriving the optimal thread count from the number of scanlines total?
> If the image is 5x120 the algorithm will separate the picture (at 4 cores) to four 5x30 image, but for so small images the overhead much bigger then the gain.
> Our experience showed the overhead disappears below approx. 256x256 pixel per thread.
> You should also consider there 120x5 image which is also not a good candidate for parallelization so we should check the if the image has the minimum area(width * height) and a minimum scaleline as well.
> And must be sure that the count of threads not be more than the height of the image.

Fair enough. So what about a 100x1000 image? That would use a single thread with this formula, and seems like an awesome candidate for more parallelization. (Please correct me if I'm wrong. :)

> > I like that you're sharing the code between the threaded and non-threaded paths.
> > Could we refactor it slightly to look less thread-specific?
> > For example having a transformColorSpace(yStart, yEnd, width, bits, bytesPerLine, lookupTable) method instead of passing a ThreadParameters object.
> > Then the non-threading code doesn't need to know about ThreadParameters.
> Not, the worker function must be get only one parameter. That is a limitation of Parallel_Jobs API.

The worker function could be a one-liner that calls an inline function with the appropriate parameters.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list