Re: [PATCH] Making Update::SinglePar work inside insets
On Mon, Jul 17, 2023 at 11:19:22PM +0200, Jean-Marc Lasgouttes wrote: > What I cannot fix easily, though is that if I insert characters just before > the branch (in same paragraph), things are ugly again because the whole > branch has to be typeset again and again. Indeed, that is still slow. In any case, the situation is much improved! Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Making Update::SinglePar work inside insets
Le 17/07/2023 à 18:00, Scott Kostyshak a écrit :
On Mon, Jul 17, 2023 at 04:03:32PM +0200, Jean-Marc Lasgouttes wrote:
Hello,
This patch tries to address #12297, where typing in the big branch in the
attached big-inset.23.lyx file is painfully slow.
Works well! I just did some brief testing.
It worked well until one tries to use mathed %-] Updated patch below is
better in this respect.
Works well! I just did some brief testing. Scrolling is still slow, but with your patch
typing and returns are much faster, and even "workable" (in the sense that if
there were no scrolling issue I could imagine editing the document without too much
frustration).
Indeed. The good news is that in principle LyX has already (painfully)
computed all the needed metrics for scrolling, so in principle it should
not be impossible to fix.
What I cannot fix easily, though is that if I insert characters just
before the branch (in same paragraph), things are ugly again because the
whole branch has to be typeset again and again.
JMarcFrom c48f313d27b0bede0829877fb65100ad388ca3e3 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes
Date: Mon, 17 Jul 2023 14:43:29 +0200
Subject: [PATCH] Enable Update::SinglePar in nested insets too
The idea of single par update is to try to re-break only the paragraph
containing the cursor (if this paragraph contains insets etc.,
re-breaking will recursively descend).
The existing single paragraph update mechanism was tailored to work
only at top level. Indeed changing a paragraph nested into an inset may
lead to larger changes.
This commit tries a rather naive approach that seems to work well: we
need a full redraw if either
1/ the height has changed
or
2/ the width has changed and it was equal to the text metrics width;
the goal is to catch the case of a one-row inset that grows with
its contents, but optimize the case of typing in a short paragraph
part of a larger inset.
NOTE: if only the height has changed, then it should be
possible to update all metrics at minimal cost. However,
since this is risky, we do not try that right now.
Part of bug #12297.
---
src/BufferView.cpp | 41 ++---
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index 15911e8ff3..f30e656477 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -3023,24 +3023,35 @@ Cursor const & BufferView::cursor() const
bool BufferView::singleParUpdate()
{
- Text & buftext = buffer_.text();
- pit_type const bottom_pit = d->cursor_.bottom().pit();
- TextMetrics & tm = textMetrics();
- Dimension const old_dim = tm.parMetrics(bottom_pit).dim();
+ pit_type const pit = d->cursor_.pit();
+ TextMetrics & tm = textMetrics(d->cursor_.text());
+ Dimension const old_dim = tm.parMetrics(pit).dim();
// make sure inline completion pointer is ok
if (d->inlineCompletionPos_.fixIfBroken())
d->inlineCompletionPos_ = DocIterator();
- // In Single Paragraph mode, rebreak only
- // the (main text, not inset!) paragraph containing the cursor.
- // (if this paragraph contains insets etc., rebreaking will
- // recursively descend)
- tm.redoParagraph(bottom_pit);
- ParagraphMetrics & pm = tm.parMetrics(bottom_pit);
- if (pm.height() != old_dim.height()) {
- // Paragraph height has changed so we cannot proceed to
- // the singlePar optimisation.
+ /* Try to rebreak only the paragraph containing the cursor (if
+ * this paragraph contains insets etc., rebreaking will
+ * recursively descend). We need a full redraw if either
+ * 1/ the height has changed
+ * or
+ * 2/ the width has changed and it was equal to the textmetrics
+ *width; the goal is to catch the case of a one-row inset that
+ *grows with its contents, but optimize the case of typing at
+ *the end of a mmultiple-row paragraph.
+ *
+ * NOTE: if only the height has changed, then it should be
+ * possible to update all metrics at minimal cost. However,
+ * since this is risky, we do not try that right now.
+ */
+ tm.redoParagraph(pit);
+ ParagraphMetrics & pm = tm.parMetrics(pit);
+ if (pm.height() != old_dim.height()
+ || (pm.width() != old_dim.width() && old_dim.width() == tm.width())) {
+ // Paragraph height or width has changed so we cannot proceed
+ // to the singlePar optimisation.
+ LYXERR(Debug::PAINTING, "SinglePar optimization failed.");
return false;
}
// Since position() points to the baseline of the first row, we
@@ -3048,11 +3059,11 @@ bool BufferView::singleParUpdate()
// the height does not change but the ascent does.
pm.setPosition(pm.position() - old_dim.ascent() + pm.ascent());
- tm.updatePosCache(bottom_pit);
+ tm.updatePosCache(pit);
LYXERR(Debug::PAINTING, "\ny1: " << pm.position() - pm.ascent()
<< " y2: " << pm.position() + pm.descent()
- << " pit: " << bottom_pit
+ << " pit: " << pit
<< " singlepar: 1");
return true;
}
--
2.39.2
--
lyx-devel mailing list
Re: ./configure goes through, build fails with no library
Le 17/07/2023 à 21:14, Enrico Forestieri a écrit : Take into account that modules differ from a Qt version to another, so we would still need 3 different paths. A helper function with parameters? Moreover, I think that the Qt4 version would need a different approach, even if the info can be obtained by qmake. I recall that André even put up a build system based on qmake ;) The good thing about Qt4 is that we removed support for it :) JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ./configure goes through, build fails with no library
On Mon, Jul 17, 2023 at 08:59:13PM +0200, Jean-Marc Lasgouttes wrote: Le 17/07/2023 à 20:56, Enrico Forestieri a écrit : I expect it to work with Qt5, at least. But why should we do that? Remember: don't fix it if it ain't broken. Because the rest is a mess and we have now 3 different paths to do the same thing. Are there known cases where qmake is not enough for our needs? Take into account that modules differ from a Qt version to another, so we would still need 3 different paths. Moreover, I think that the Qt4 version would need a different approach, even if the info can be obtained by qmake. I recall that André even put up a build system based on qmake ;) -- Enrico -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ./configure goes through, build fails with no library
Le 17/07/2023 à 20:56, Enrico Forestieri a écrit : I expect it to work with Qt5, at least. But why should we do that? Remember: don't fix it if it ain't broken. Because the rest is a mess and we have now 3 different paths to do the same thing. Are there known cases where qmake is not enough for our needs? JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ./configure goes through, build fails with no library
On Mon, Jul 17, 2023 at 03:56:40PM +0200, Jean-Marc Lasgouttes wrote: This is great. Concerning replacing most of the qt.m4 code with the qmake-based solution, would you expect it to work? This is post-2.4, of course. I expect it to work with Qt5, at least. But why should we do that? Remember: don't fix it if it ain't broken. -- Enrico -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Support protected and thin space in simple search (#12836)
Am Mon, 17 Jul 2023 15:46:34 +0200 (CEST) schrieb Juergen Spitzmueller : > commit f6f936e3d049c05ad0795c32696df895d8b61313 > Author: Juergen Spitzmueller > Date: Mon Jul 17 16:58:04 2023 +0200 > > Support protected and thin space in simple search (#12836) Thanks. Kornel pgpiaSVrj9D3J.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Making Update::SinglePar work inside insets
On Mon, Jul 17, 2023 at 04:03:32PM +0200, Jean-Marc Lasgouttes wrote: > Hello, > > This patch tries to address #12297, where typing in the big branch in the > attached big-inset.23.lyx file is painfully slow. > > To this end, I made BufferView::singleParUpdate, and the result looks great. > Since the changes are pretty minimal, I wonder what I did miss. > > I would be happy if this patch could get some testing in two respects: > > 1/ what are the cases where is breaks screen rendering? > > 2/ what are the operations that are still too slow with the test file? Works well! I just did some brief testing. Scrolling is still slow, but with your patch typing and returns are much faster, and even "workable" (in the sense that if there were no scrolling issue I could imagine editing the document without too much frustration). Thanks for working on this! Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ./configure goes through, build fails with no library
Le 15/07/2023 à 15:31, Enrico Forestieri a écrit : On Sat, Jul 15, 2023 at 01:47:56PM +0200, Jean-Marc Lasgouttes wrote: Le 15/07/2023 à 13:44, Enrico Forestieri a écrit : It suffices replacing LYX_WARNING with AC_MSG_ERROR. However, in this case configure stops there. This is whaty we do now if Qt cannot beconfigure properly. Warnings are for cases where people can compile, but some things are not completely right. Patch amended as above and committed at 99f972e2. This is great. Concerning replacing most of the qt.m4 code with the qmake-based solution, would you expect it to work? This is post-2.4, of course. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Assure language is properly closed before non-inheriting inset.
On Mon, Jul 17, 2023 at 01:21:07PM +0200, Jürgen Spitzmüller wrote: > Am Sonntag, dem 16.07.2023 um 17:00 -0400 schrieb Scott Kostyshak: > > I only get the exception when compiling the ja Math.lyx from the > > 2.3.x branch. > > I see, thanks. Should be fixed. Thanks, looks good. I took a look at the diffpdf (the original issue that motivated this) and I think it's better now. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Assure language is properly closed before non-inheriting inset.
Am Sonntag, dem 16.07.2023 um 17:00 -0400 schrieb Scott Kostyshak: > I only get the exception when compiling the ja Math.lyx from the > 2.3.x branch. I see, thanks. Should be fixed. -- Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
