Re: outline pane issues and huge note slowness

[V K]

On Wednesday, October 27, 2021, 03:45:32 PM GMT+3, Jean-Marc Lasgouttes 
 wrote: 





Le 27/10/2021 à 05:16, V K a écrit :


The problem is that, besides the versions, the precise layout of the 
binaries may differ. Therefore, I would have to clone your OS in a VM to 
be able to read the perf.data file.



I see. That's pity.


Recent unreleased version of hotspot allow to save a portable file, but 
I could not get it to work in my trials. They are available here:
https://github.com/KDAB/hotspot/releases
(take the appImage file and make it runnable).





I downloaded appImage, it doesn't like Wayland (error qt.qpa.plugin: Could not 
find the Qt platform plugin "wayland-egl" in "") but I can launch it in 
xwayland mode. So I should record Lyx with Hotspot and save as .perfparser file?

Valdemaras
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: END-OF-FRAME, once again..

[Daniel]

On 2021-10-27 20:02, Virgil Arrington wrote:

*From: *Daniel 
*Sent: *Wednesday, October 27, 2021 11:03 AM
*To: *lyx-users@lists.lyx.org 
*Subject: *Re: END-OF-FRAME, once again..


 > However, if you look at the LaTeX source code, you see that the last two
are not actually frames, i.e. the content is not in a frame environment.
Separators are general, i.e. they do not say what kind of environment
they separate. One always needs a frame environment to create a "proper"
frame.

By golly, it looks like you’re right. I had only looked at the compiled 
output, which showed that last two “frames” as frames when in fact, they 
just happened to split at the frame because of the amount of stuff in 
each paragraph each. I hadn’t bothered to look at the LaTeX code. I just 
went in to the MWE and drastically reduced the amount of text on the 
penultimate “slide” and size of the picture on the last “slide” and, 
when compiled, it all appeared on one slide even though I kept the 
end-of-frame marker in place.


So, it seems that, without a Frame environment, the end-of-frame marker 
does nothing, and without an end-of-frame marker, a Frame environment 
doesn’t work properly.


Interesting. It does make one wonder why this has to be the case, since 
LyX is seemingly able to \begin and \end any other environment without 
an explicit \end marker.


I think the issue is that with frames, you want to have two paragraphs 
with the same type of environment directly after each other. In that 
case LyX just combines the paragraphs into one environment. Not only 
with frames but any environment.


That is where I suggests things could be done differently. Instead of 
continuing the same environment, LyX should just start a new one.


However, there are cases where it might seem more natural to combine 
consecutive paragraphs into one environment. One rather clear example 
are lists because new items cannot be created via an indented standard 
paragraph.


I am not sure about Quote, Verse, etc. One would have to think more 
about further distinctions.


Daniel

--
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: outline pane issues and huge note slowness

[Jean-Marc Lasgouttes]

Le 27/10/2021 à 19:25, V K a écrit :

I downloaded appImage, it doesn't like Wayland (error qt.qpa.plugin: Could not find the Qt platform 
plugin "wayland-egl" in "") but I can launch it in xwayland mode. So I should 
record Lyx with Hotspot and save as .perfparser file?


Yes if it works. In my testing for some reason it created a 0-sized file

JMarc
--
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

RE: END-OF-FRAME, once again..

[Virgil Arrington]

From: Daniel
Sent: Wednesday, October 27, 2021 11:03 AM
To: lyx-users@lists.lyx.org
Subject: Re: END-OF-FRAME, once again..


> However, if you look at the LaTeX source code, you see that the last two
are not actually frames, i.e. the content is not in a frame environment.
Separators are general, i.e. they do not say what kind of environment
they separate. One always needs a frame environment to create a "proper"
frame.


By golly, it looks like you’re right. I had only looked at the compiled output, 
which showed that last two “frames” as frames when in fact, they just happened 
to split at the frame because of the amount of stuff in each paragraph each. I 
hadn’t bothered to look at the LaTeX code. I just went in to the MWE and 
drastically reduced the amount of text on the penultimate “slide” and size of 
the picture on the last “slide” and, when compiled, it all appeared on one 
slide even though I kept the end-of-frame marker in place.

So, it seems that, without a Frame environment, the end-of-frame marker does 
nothing, and without an end-of-frame marker, a Frame environment doesn’t work 
properly.

Interesting. It does make one wonder why this has to be the case, since LyX is 
seemingly able to \begin and \end any other environment without an explicit 
\end marker.

Virgil



--
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users



LyX-Test.lyx
Description: LyX-Test.lyx
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: END-OF-FRAME, once again..

[Daniel]

On 27/10/2021 11:33, UD K wrote:



On 10/27/21 11:03 AM, Daniel wrote:

On 26/10/2021 01:31, Virgil Arrington wrote:

*> From: *UD K 

 >  I think that your experience confirms my feeling that it 
shouldn't HAVE to be that hard.


I agree; it shouldn’t be that hard. To me it would make sense to have 
the selection of the “Frame” environment automatically create a new 
slide without the need for a separate end of frame marker. However, I 
suppose there may be some folks who want to use the “Frame” 
environment for some content other than the Frame title. For them, we 
could have a “Frame-New-Slide” environment that would automatically 
create a new slide.


That’s the way it works in Markdown. Just put a heading hashtag # 
before your text and that line becomes the title of the new slide. 
Easy as pie.


Virgil




Since both of you replied but didn't directly commented on my 
suggestion (basically, use increased depth/indentation for stuff that 
should go on a frame which makes the whole separator machinery 
unnecessary between frames), I am wondering whether you had any 
thoughts about it or whether the suggestion isn't clear enough.


Daniel


Daniel,
I can only speak for myself.  Since I am not a developer, and know 
nothing about what is behind the screen of Lyx/Beamer, I assume that 
there is a (valid?) reason behind the need for an End-Of-Frame, without 
which, presumably, things will go fall apart.  All I know is that it IS 
difficult, right now, and --  I suspect-- does not need to be.


I can understand that you are worried about making constructive 
suggestion because you don't know all the details. However, I agree with 
Scott who is actually one of the developers, that it is still worthwhile 
to make suggestions. You just need to be comfortable with your 
suggestion meeting criticism or, worst case, not getting attention. So, 
you need to make up your mind whether you are comfortable with this.


As for the development. In my experience, there are always things that 
seem like a good or simple idea at first but might not seem ideal later 
on. Furthermore, LyX has only a small developer team with little time at 
their hands and small user base that provides feedback, so it is not 
completely surprising if that happens more frequently.


Daniel

--
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: END-OF-FRAME, once again..

[Daniel]

On 27/10/2021 15:38, Virgil Arrington wrote:
I just happened to notice with my own MWE that the LyX compiler doesn’t 
count slides that don’t have Frame environment titles.


So, even with the End-of-Frame markers, I’ve noticed two things that 
make a Frame environment necessary. First, without it, I’m unable to 
nest subsequent paragraphs on the frame and second, without it, the 
slide doesn’t get numbered in the presentation.


Virgil


Good idea. I did not consider this before.

However, if you look at the LaTeX source code, you see that the last two 
are not actually frames, i.e. the content is not in a frame environment. 
Separators are general, i.e. they do not say what kind of environment 
they separate. One always needs a frame environment to create a "proper" 
frame.


Actually, in your case, the separator has only the function that they 
begin a new paragraph (rather than a new frame). But this can also be 
achieved by just starting a new line. You can actually remove the last 
two separators and it will look exactly the same. The frames are only 
broken at the paragraph breaks.


Furthermore, even if one needs a separator in certain cases, this 
doesn't mean that the other cases couldn't be better handled without.


Daniel

--
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

RE: END-OF-FRAME, once again..

[Virgil Arrington]

> On 10/27/21 Ehud wrote:

> On 10/27/21 11:03 AM, Daniel wrote:

> Since both of you replied but didn't directly commented on my suggestion 
> (basically, use increased depth/indentation for stuff that should go on a 
> frame which makes the whole separator machinery unnecessary between frames), 
> I am wondering whether you had any thoughts about it or whether the 
> suggestion isn't clear enough.

> Daniel
  > Daniel,
  > I can only speak for myself.  Since I am not a developer, and know nothing 
about what is behind the screen of Lyx/Beamer, I assume that there is a 
(valid?) reason behind the need for an End-Of-Frame, without which, presumably, 
things will go fall apart.  All I know is that it IS difficult, right now, and 
--  I suspect-- does not need to be.


  > Ehud Kaplan

I think Ehud may have a point that I had overlooked. My solution to have new 
frames always begin with a Frame environment assumes that one always wants a 
Frame title on a slide. If I understand Daniel’s suggestion, I think it assumes 
that the user always wants some level of nesting of information on a slide.

I suppose there may be times when one just wants a slide without a Frame title. 
In such a case one needs some end of frame marker other than a Frame title 
environment. I’ve attached an MWE to demonstrate various ways of creating 
slides. Not all of these slides would be possible without a separate 
end-of-frame marker.

I have to keep reminding myself that other users may have needs different from 
mine and that those needs may require different software solutions.

In an earlier email, I had mentioned the way Markdown does it with a new slide 
being generated by a slide title Header hashtag (#) as below:

# Slide Title
- Bullet item
   - Nested Bullet item

# A New Slide

But, some Markdown slide generators (such as Landslide or Darkslide) require a 
separate end-of-frame marker:

# Slide Title
- Bullet item
   - Nested Bullet item
---

# New Frame Title
- And so on…

I had always wondered why Landslide and Darkslide would have a frame separator 
(---). I had always thought that a new frame title should be sufficient (as it 
is with Slidy or Ioslides). But, I can how that is only because my slides 
*always* have titles. For those who don’t want slide Titles (and I’m seeing 
this more and more), some other way of identifying a new slide is required.

I don’t envy software developers. It must be a bear to try to meet all of the 
different needs we end users have.

Virgil





LyX-Test.lyx
Description: LyX-Test.lyx
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: outline pane issues and huge note slowness

[Jean-Marc Lasgouttes]

Le 27/10/2021 à 05:16, V K a écrit :


HEAD was master, not breakrows. I don't know what was wrong, so I deleted Lyx 
git folder on my machine and cloned Lyx from git anew. After that compiled 
master with --enable-build-type=prof – huge notes were very slow, almost 
stalled. I compiled breakrows branch with --enable-build-type=prof and huge 
notes are usable. Performance is much better than it was in master. There is 
some, how to say, jerking, lagging when scrolling, scrolling isn't smooth, 
there is a lag, but I can scroll insets almost freely. This is huge progress. 
Maybe master waits it :).


Good to know, I will propose it. I was waiting for good reasons :)


I can help with testing (not this week though). I don't know anything about 
profiler, but installed Hotspot, launched lyxgit (that is my prefix of master 
Lyx) with default parameters. Now I have 56 MiB perf.data file. Versions of 
packages are there, I think (except those from Arch linux Aur), if you need 
that information: 
https://lists.manjaro.org/pipermail/manjaro-packages/Week-of-Mon-20211011/042684.html
There is parser errors like "Module "libQt5Gui.so.5.15.2" is missing 1587 of 2089 
debug symbols." and so on. So I can send perf.data file to you.


The problem is that, besides the versions, the precise layout of the 
binaries may differ. Therefore, I would have to clone your OS in a VM to 
be able to read the perf.data file.


Recent unreleased version of hotspot allow to save a portable file, but 
I could not get it to work in my trials. They are available here:

https://github.com/KDAB/hotspot/releases
(take the appImage file and make it runnable).

Otherwise, we could try to run "perf cord" and create a report by hand. 
I'll take a look and come back to you when I have time.


JMarc
--
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: END-OF-FRAME, once again..

[UD K]

On 10/27/21 11:03 AM, Daniel wrote:

On 26/10/2021 01:31, Virgil Arrington wrote:

*> From: *UD K 

 >  I think that your experience confirms my feeling that it 
shouldn't HAVE to be that hard.


I agree; it shouldn’t be that hard. To me it would make sense to have 
the selection of the “Frame” environment automatically create a new 
slide without the need for a separate end of frame marker. However, I 
suppose there may be some folks who want to use the “Frame” 
environment for some content other than the Frame title. For them, we 
could have a “Frame-New-Slide” environment that would automatically 
create a new slide.


That’s the way it works in Markdown. Just put a heading hashtag # 
before your text and that line becomes the title of the new slide. 
Easy as pie.


Virgil




Since both of you replied but didn't directly commented on my 
suggestion (basically, use increased depth/indentation for stuff that 
should go on a frame which makes the whole separator machinery 
unnecessary between frames), I am wondering whether you had any 
thoughts about it or whether the suggestion isn't clear enough.


Daniel


Daniel,
I can only speak for myself.  Since I am not a developer, and know 
nothing about what is behind the screen of Lyx/Beamer, I assume that 
there is a (valid?) reason behind the need for an End-Of-Frame, without 
which, presumably, things will go fall apart.  All I know is that it IS 
difficult, right now, and --  I suspect-- does not need to be.


--
Ehud Kaplan

-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: END-OF-FRAME, once again..

[Daniel]

On 26/10/2021 01:31, Virgil Arrington wrote:

*> From: *UD K 

 >  I think that your experience confirms my feeling that it shouldn't 
HAVE to be that hard.


I agree; it shouldn’t be that hard. To me it would make sense to have 
the selection of the “Frame” environment automatically create a new 
slide without the need for a separate end of frame marker. However, I 
suppose there may be some folks who want to use the “Frame” environment 
for some content other than the Frame title. For them, we could have a 
“Frame-New-Slide” environment that would automatically create a new slide.


That’s the way it works in Markdown. Just put a heading hashtag # before 
your text and that line becomes the title of the new slide. Easy as pie.


Virgil




Since both of you replied but didn't directly commented on my suggestion 
(basically, use increased depth/indentation for stuff that should go on 
a frame which makes the whole separator machinery unnecessary between 
frames), I am wondering whether you had any thoughts about it or whether 
the suggestion isn't clear enough.


Daniel

--
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: outline pane issues and huge note slowness

[V K]

On Monday, October 25, 2021, 02:21:38 PM GMT+3, Jean-Marc Lasgouttes 
 wrote: 





Good. Did you configure with "--enable-build-type=prof" ? This is 
important because by default master will compile with some run-time 
checks that lower the performance.




I didn't know that key. Thank you. I compiled master (without breakrows) with 
it and strangely huge insets were noticeable more slow than without it. Maybe 
some master updates changed performance, or this key.

> "git pull features breakrows"
> After that I compiled Lyx with autogen etc.


> Hugenotes are slow, similar to master, maybe a tad better. And I doubt – 
> maybe it is master without breakrows branch. I don't see anything about that 
> branch in Lyx info. Version info:

If it is the breakrow branch, then "git log" will start like:

commit 5f33a0ea1971e924c4959b9a003ed548871153ab (HEAD -> breakrows, 
features/breakrows)
Author: Jean-Marc Lasgouttes 
Date:  Tue Oct 12 11:33:23 2021 +0200

    One less thing to do in PAINTING_ANALYSIS


It is disappointing that the situation is not better. However, I am not 
able to reproduce you problem on my system, and I do not understand why. 
My core i7 7700T is not fundamentally faster than your core i7 6600U.

If you have some more time, we can try to find out why it is not that 
fast. To do that, the idea would be to run a profiler like hotspot. Do 
you have any experience with that?

Unfortunately, I did not find a way to let you send me the full profiler 
data, since it depends of the precise version of all the components of 
your system.




HEAD was master, not breakrows. I don't know what was wrong, so I deleted Lyx 
git folder on my machine and cloned Lyx from git anew. After that compiled 
master with --enable-build-type=prof – huge notes were very slow, almost 
stalled. I compiled breakrows branch with --enable-build-type=prof and huge 
notes are usable. Performance is much better than it was in master. There is 
some, how to say, jerking, lagging when scrolling, scrolling isn't smooth, 
there is a lag, but I can scroll insets almost freely. This is huge progress. 
Maybe master waits it :).

I can help with testing (not this week though). I don't know anything about 
profiler, but installed Hotspot, launched lyxgit (that is my prefix of master 
Lyx) with default parameters. Now I have 56 MiB perf.data file. Versions of 
packages are there, I think (except those from Arch linux Aur), if you need 
that information: 
https://lists.manjaro.org/pipermail/manjaro-packages/Week-of-Mon-20211011/042684.html
 
There is parser errors like "Module "libQt5Gui.so.5.15.2" is missing 1587 of 
2089 debug symbols." and so on. So I can send perf.data file to you.

Valdemaras
-- 
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users