Bug 137794 - FILEOPEN: QT5 VCL with default renderer (not cairo) is much slower at opening slides
Summary: FILEOPEN: QT5 VCL with default renderer (not cairo) is much slower at opening...
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
7.0.2.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Qt5
  Show dependency treegraph
 
Reported: 2020-10-27 11:21 UTC by Callegar
Modified: 2021-09-15 03:39 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Callegar 2020-10-27 11:21:50 UTC
Description:
Trying to track the progress of the QT5 VCL, I have tried opening some impress documents with the QT5 VCL.

Unless I also use SAL_VCL_QT5_USE_CAIRO, the rendering of the fonts in my slides is extra bad (which I think is expected for the time being). However, I have also noticed that the slides are much much slower to open.

Since I haven't seen this reporting, I though it may be useful to have it on the tracker.

Steps to Reproduce:
Open a document with
SAL_USE_VCLPLUGIN=qt5 libreoffice7.0 document.odp
and
SAL_USE_VCLPLUGIN=qt5 SAL_VCL_QT5_USE_CAIRO=1 libreoffice7.0 document.odp

Actual Results:
Without SAL_VCL_QT5_USE_CAIRO=1 opening the document is quite slow.

Expected Results:
Speed to open the document should be approximately the same.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.0.3.1
Build ID: d7547858d014d4cf69878db179d326fc3483e082
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: qt5
Locale: it-IT (it_IT.utf8); UI: en-US
Calc: threaded
Comment 1 Jan-Marek Glogowski 2020-10-27 16:18:00 UTC
(In reply to sergio.callegari from comment #0)
> Description:
> Trying to track the progress of the QT5 VCL, I have tried opening some
> impress documents with the QT5 VCL.
> 
> Unless I also use SAL_VCL_QT5_USE_CAIRO, the rendering of the fonts in my
> slides is extra bad (which I think is expected for the time being). However,
> I have also noticed that the slides are much much slower to open.

I wouldn't have high hopes and it's not "expected for the time being".

Unless someone decides to use not just LO's own text layouting code (which uses harfbuzz anyway, like almost everyone), but also LO's native (AKA platform dependent) font drawing code to replace Qt's own font drawing, the only thing to do would be fixing Qt. My personal target is Qt only, but all patches welcome. Or on Linux to use Cairo graphics as a workaround with a little blitting overhead.

The Qt5 VCL plugin completely relies on Qt for font handling, so it uses QFont, QGlyphRun and QPainter::drawGlyphRun. This way it can also work on all Qt supported platforms without any "native" code (tested once on MacOS and Win).
Comment 2 Xisco Faulí 2021-02-15 18:09:05 UTC
Hello sergio.callegari@gmail.com,
I believe this issue might be fixed now after
https://git.libreoffice.org/core/commit/27a4aea50a9efa5c839b0ae2de1f9f14a7782f11.
Could you please try to reproduce it with a master build from
http://dev-builds.libreoffice.org/daily/master/ ?
You can install it alongside the standard version.
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the master build
Comment 3 QA Administrators 2021-08-15 03:46:55 UTC Comment hidden (obsolete)
Comment 4 QA Administrators 2021-09-15 03:38:57 UTC
Dear sergio.callegari,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp