I actually thought abotu thread a logn way back and its not hard...
just split image to blend/scale/render into N sections vertically (N
equal sized strips) ands have each thread handle each strip. all
ttherad wait till busy count > 0 - onec its < 1 all threads are done
and function can actually return to application control.
-> For instance, what if all your API functions did was queue drawing
-> requests, and you had a single long-lived worker thread taking requests
-> off the queue and executing them? (Or maybe two worker threads, if
-> you like.) That way, you'll allow the user's app to run in parallel with
-> your rendering, and you'll only have a single interface across which
-> to worry about thread safety.
not how it works at the lib api - it's all immediate mode
design/implimentation. any queued drawing shoudl/would happen at a much
higher level in the calling application or toolkit. thats how i'd doign
it now ahyway with queueing happinign at the visual objedt/widget
stage. the aim is to spend as little time inside an api call as
possible and long-lived crunching calls like blending an 800x600 RGBA
image onto another woudl do well with being split into threads for
multiple cpu boxes :)
-> The cost would be that the caller would not be allowed to change
-> stuff he passed pointers to until your API was done with it.
-> And therein lies the design challenge.
-> - Dan
->
-- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) raster@rasterman.com raster@valinux.com raster@enlightenment.org raster@linux.com raster@zip.com.au
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/