Luboš Luňák
089a4f2453
- it's in practice never used nowadays, group threading has higher priority in the code and since SwInterpreter's allowed opcodes are a subset of group threading's, there should be no formula where control flow gets as far as using SwInterpreter - the only opcodes SwInterpreter allows are ocAdd, ocSub, ocMul, ocDiv, ocSum and ocProduct, which is a rather limited set and group threading should handle all that as well - if SwInterpreter performs anything better than group threading, there shouldn't be a problem doing the same for group threading - it's yet another code path that should be handled, tested, etc. and the added complexity is not worth it - it shares some code with OpenCL handling, which is both added hassle in case OpenCL code needs changes, and it also causes confusion such as people thinking SwInterpreter has something to do with OpenCL Change-Id: I99052862b60b6266c70dd436d1d7938177dc6bd9 Reviewed-on: https://gerrit.libreoffice.org/58643 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
Helper functionality for implementing UNO components ...anything not generic/mature enough to end up in URE's stable interface at cppuhelper etc.