Le 24/05/2016 09:49, Jean-Marc Lasgouttes a écrit :
Le 24/05/2016 à 00:51, Guillaume Munch a écrit :
Do you know any other bug on Linux+qt5.5.1 than
http://www.lyx.org/trac/ticket/9731 ?
Because on the other hand with qt4 there is the critical
http://www.lyx.org/trac/ticket/9362. I also noticed that lyx is
very slow with qt4 now, with profiling showing that most of the
time is spent in QTextLine::setLineWidth() below
GuiFontMetrics::breakAt(). In fact I find it more annoying than
#9731, so much that I switched to 5.5.1. I wonder whether LyX 2.2
should not be built with qt >= 5.5.1 on Linux when possible.
Could you give more details? I do all my development in 4.8, so I am
a bit surprised. Or maybe I missed how fast it is now with 5.6 :)
Anyway, the new code is faster for me with 4.8 than the old one.
It really feels fast with qt5 :)
The protocol is to change the width of the window (all other things equal).
Qt4: 75% of the time is spent (in number of instructions) inside
QTextEngine::shapeText(). Of these 75%, 2/3 is requested by metrics
calculation (QTextLine::setLineWidth() from GuiFontMetrics::breakAt())
and 1/3 by painting (GuiPainter::text()). Ultimately, 74% of the time
is spent in in FT_Load_Glyph and FT_Render_Glyph from
libfreetype.so.6.12.1 (thus, including the metrics phase).
Qt5: QTextEngine::shapeText() only accounts for 13.22% of the cycles,
and costs 28 times less per call (69729 instructions vs 1932642).
QTextLine::setLineWidth() only costs 4% total. GuiPainter::text() costs
21%, with time spent in a certain QRasterPaintEngine::drawCachedGlyphs().
Conclusion: using QTextLine::setLineWidth() breaking rows is very costly
with qt4.8.7, and much less with qt5. I agree with you that I do not
remember seeing this slowness before, and I do not know what exactly
could trigger this behaviour.
Let me know if you need more details.
For these reasons as well, I am hoping that for 2.3 the community
of LyX developers will choose to focus on qt >= 5.6.
With Ubuntu 14.04 offering 5.2.1 and 16.04 offering 5.5.1, this
seems premature to me, especially when the cost of supporting 4.8 is
low for now as far as I can see. We shall of course remove support
for Qt < 4.8.
Note that, as I wrote on the tracker, the bug that prompted Scott to
recommend qt5.5 probably comes from the same wrong use of
ShortcutOverride, and therefore the requirement for qt5 could be lowered
(I remember that qt5.4 was quite usable without this bug).
Le 24/05/2016 20:40, Jean-Marc Lasgouttes a écrit :
Le 24/05/16 à 21:31, Georg Baum a écrit :
On linux most people do not compile qt themselves, and simply
use the preinstalled version, because it is so much easier. Those
who do compile qt are experts, I trust them to choose a good
version.
Unless the question is choosing between qt4 and qt5 :)
For these reasons as well, I am hoping that for 2.3 the community
of LyX developers will choose to focus on qt >= 5.6.
+1
However, I also agree with Jean-Marc: As long as keeping LyX
compilable with qt 4.8 is close to zero effort we should support
4.8 as in "LyX compiles and does not crash immediately".
I do not mind including the occasional #if #else for Qt4 if this does
not involve much effort. By focusing on qt >= 5.6, I mean that I would
not like to be discouraged from using new features if the opportunity
arises. So, let's keep the door open for discussing dropping qt4.8
once a concrete motivation arises (for instance I was curious about Qt
Quick, but this appears to exist in Qt4.8 already). I also meant that we
can expect to discover many bugs during the ongoing transition to qt5,
especially in the high-dpi category, and qt5.6 is seems very different
from qt5.5 in this area.
I also wonder whether the --enable-qt5 option should be made default
starting from 2.3.
In the foreseeable future, I will compile and use 4.8.x. Actually, I
have no real incentive to switch to Qt5 in Linux, so I will act as
the resident old-timer, until the cost is too high.
One of my concerns was spending efforts on qt4 compatibility without
anybody to provide feedback during development. Thank you for playing
this necessary role.
I guess that one problem will be with the UI files.
I guess we will have to see.
Guillaume
