Description: Make SKIA default. Move OpenGL and GDI rendering options to Expert configuration.. Likely already considered, but I report it anyway I prefer one good working backend to multiple somewhat broken backends. Skia is stable enough & looks promising. I would prefer everybody using/testing/focusing on Skia. Of course, other backends can be 'workaround' or practical for comparison. However the ideally shouldn't be used. It's hard to keep track of all those backend related issues. From AQ POV as for DEV POV. Note: this approach assumes a rather quick SKIA bug fixing after release for the issues missed while (alpha/beta) testing. Steps to Reproduce: - Actual Results: - Expected Results: - Reproducible: Always User Profile Reset: No Additional Info: -
CC Lubos. Skia is already the default on Windows where most desktop users are. Moving GL and GDI to expert options may be a good idea: skia has its own vulkan and raster backends, so there should be no excuse not to use it. And that would help towards an actual removal of the GL code in the future. QA can still use the environment variables in vcl/README.vars in case some testing specific to a backend is needed. Do you want to add this to the Skia tracker?
A Tools -> Options -> View with just 'Use anti-alaising'; and a checkbox for Skia's: 'Use Skia' (i.e. Vulkan), 'Ignore black list', or 'Force Skia software rendering' (i.e. Raster) modes--is premature. As the Skia implementatio matures, I could see moving the OpenGL related settings to Expert Configuration near term (eventually removing), but the checkbox to disable Skia, and enable either CPU or the Hardware Acceleration rendering is still useful. Though the Hardware Acceleration check box seems less relevant of late.
On pc Debian x86-64 with master sources updated today, I got: Version : 7.0.0.0.alpha0+ Build ID : 0b48cee16d459d27ebd090d008ec9398c86fc581 Threads CPU : 12; OS : Linux 5.5; UI Render : par défaut; VCL: gtk3; Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded So no OpenGL or Skia by default, idem for LO Debian package 6.4.3. IMHO, considering the number of bugs present in https://bugs.documentfoundation.org/show_bug.cgi?id=129062, knowing that Skia is used by few people for the moment, I think it's premature and we shouldn't rush on it. Indeed, I'd like to avoid Firebird experience when it's been removed from experimental followed by a lot of bugs reported. However, I'm not fan of OpenGL considering the number of bugs there are (because of buggy drivers or the fact that OpenGL part is hardly maintained in LO, whatever) and know that there are GDI leaks. So if the default rendering on Windows uses GDI, I could understand the Skia option for Windows only (at least for the moment).
Just to be sure not to be misunderstood, I consider Luboš does a great job about Skia. However: - I'm not an expert but I know that rendering part is a central and complicate part in LO - 95% of patches related to Skia are made by Luboš so what will happen if he doesn't want or can't work on LO anymore for any reason? Has he got some backups people? - is there some doc related to Skia implementation on LO? (didn't find on LO wiki or missed it). If no or not enough (ok everything is relative), it may be difficult for newcomers (and not only them!) to fix a bug about Skia. Having almost no fixes about Base or MacOs bugs for example is quite disappointing, let's be prudent for something like rendering.
(In reply to V Stuart Foote from comment #2) > As the Skia implementatio matures, I could see moving the OpenGL related > settings to Expert Configuration near term (eventually removing), but the > checkbox to disable Skia, and enable either CPU or the Hardware Acceleration > rendering is still useful. GDI I have no objection with GDI being around for a while longer; if Hardware Acceleration is a part of it stay's. However the should be a time path to phase it out. Marking GDI as depreciated starting with 7.0. Stopping official support with 7.0 release (except urgent cases, maybe?) The setting should move to the Expert Configuration starting with 7.3.. While dropping it at 8.0. Not written in stone.. situations can change of course, but a course must be set. OpenGL Again deprecation starting with 7.0. However, it should go faster, IMHO. The multiple choice back-ends flooding the UI; confusing. OpenGL was always somewhat broken. The DEV's aren't interested in it.. and we have to start somewhere with dropping support. And makes QA problematic.. I'm not inclined to test multiple backends for bug reports... So if XOR rendering on Skia is fast, but slow on OpenGL, not my problem.. Also, I guess all (nearly all) the Alpha testers are already using Skia.. So nobody will notice bugs sneaking into OpenGL/GDI; which is also a problem. -- About SKIA, Julien is right about the SKIA support. There needs to be more than one libreoffice developer available. And the developer should really commit to the Skia (at BoD/ESC level). Not running away at the point when the complains/bug come in.. The Firebird tragedy is combination of an immense lack of testers, and an 'broken' tender (support, cleaning up the issues afterwards, seems not to be included). Personal experience, 'developers' - i'm generalizing - are available as long as the a working on it.. story is somewhat different for bugs appearing 6 months later.. They should be committed fixed 'the flood' of bugs report asap.. Luboš is doing a great job at this point in time.. There must be a (soft) guarantee someone will support it the future ... Skia shouldn't become the next OpenGL implementation [again no offence the developers who worked on it.. it didn't turn out as expected I guess] Another question is what the targeted audience is. Is Skia Windows only. Or is/will it be also also for Mac and Linux, please let it be; yes? On what timeframe? What about the different Linux backends.. I have seen a post arguing the depreciate X11. Reducing those means more developer time for Skia and repairs being useful for a large group. LibreOffice Fresh has always been 'some sort' of beta. It can not be called that way, because everybody would skip it waiting for the final. Final never to be archived without testers. So we call it final, being a factual a beta or RC. Depending on the quality standard of the Development team. There are Beta with quality of final release. Betas with quality of a RC. RC with quality of beta. Beta with quality of Alpha.. I have seen some releasing passing by with know horrible bugs.. to be fixed in second or third .3 release. --Going even more offtopic-- About the Firebird experience Is there actually somebody in QA who is testing Base. Alex Thurgood? The Base support scarce.. at QA level as at Dev level and user base is pretty small to (and is getting even smaller as the bugs accumulate) MacOS There is no MacOS developer around, except Tor, once in a while. The code is 'legacy'. There are enough depreciation warning within the code. It still surprises me it's still working; more or less. It really needs some love. However, again a 'small' group of users.. no dev available (and or lacking the Hardware). And fixing if for 'free' while Mac users can afford Macs is still an issue. There should be specific donation campaign/ crowdfunding project.. assigned to make LibreOffice Mac great again. Or the whole Mac stuff must be commercialized.. it's already, more or less: https://apps.apple.com/us/app/collabora-office/id918120011?mt=12. Except Apple getting the biggest part of the earnings (I assume). A even worse deal, paying €29,99 and still broken.. The NeoOffice fork is a far better deal being functional; however lacking features and security fixes. However we enter the terrain of 'open source' and 'commercial interest'. Sometimes I wish that a company could hold back fixes for some time to make a 'profit'. It's impossible to earn something if say Collabora fixes Mac issues while a TDF build with the same fix is available freely immediately afterwards. We come in the area how NeoOffice handles it. With the code being open source.. however not pre-build. Which in my vision would mean, TDF holding of for a while compiling with fixes.. however, tricky area.
There are several issues mixed here, and I will adress only 2 of them: - Skia being the default, and the possible technical (and other) concerns. I think that Bugzilla is not the right place to discuss this, that should be discussed on the mailing list, so that this is not just discussed in some "random" not very visible bugreport. So if you have such generic concerns, please raise them on the mailing list. Such a discussion needs to take place before 7.0 anyway. - The configuration UI. That partially depends on the status of the implementation, and ideally maybe the settings should go away one day, but probably not now. And as this is a UI issue, I don't feel very qualified to decide this.
https://git.libreoffice.org/core/+/9dc7b88f5d3a3af0307b4ae39a01247677907d80%5E%21 removes the GL checkboxes, so the UI shouldn't be confusing anymore (expert GL options are still there). The options to disable Skia will stay for now.