From 089a4f245325a5be5cd5951d85305d791b4d9cb6 Mon Sep 17 00:00:00 2001 From: Luboš Luňák Date: Mon, 6 Aug 2018 14:55:04 +0200 Subject: remove Calc's software interpreter - 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 --- comphelper/source/misc/backupfilehelper.cxx | 2 -- 1 file changed, 2 deletions(-) (limited to 'comphelper') diff --git a/comphelper/source/misc/backupfilehelper.cxx b/comphelper/source/misc/backupfilehelper.cxx index 8bb0804739d5..d47c9904c696 100644 --- a/comphelper/source/misc/backupfilehelper.cxx +++ b/comphelper/source/misc/backupfilehelper.cxx @@ -2112,8 +2112,6 @@ namespace comphelper "ForceOpenGL", "false")); xRootElement->appendChild(lcl_getConfigElement(xDocument, "/org.openoffice.Office.Common/Misc", "UseOpenCL", "false")); - xRootElement->appendChild(lcl_getConfigElement(xDocument, "/org.openoffice.Office.Common/Misc", - "UseSwInterpreter", "false")); // write back uno::Reference< xml::sax::XSAXSerializable > xSerializer(xDocument, uno::UNO_QUERY); -- cgit