Re: Qt: was Slow scrolling

[Olivier Ripoll]

On 05.01.2012 05:16, Jerry wrote:

Do the developers monitor this list? Or does someone need to file a bug report 
for the slow scrolling problem?

Jerry


Yes, they are looking at it. If you look at the thread, you'll see 
several names of LyX developers (not exhautively: Pavel Sanda, Richard 
Heck, Jean-Marc Lasgouttes, André Pönitz)


As for the bug report, I ave the impression there are 2 bugs reported in 
the thread under the slow scrolling umbrella:


- high CPU usage and jumpy scrolling (versus smooth), as you reported in 
your message, which is what I observe also. Seems unrealetd to the OS, 
as you are on OS X, I'm on Windows 7. This bug may also be multiple 
ones, as you mention 2.0.1 also has issues while it is flawless for me 
(I do not think it is Qt-version related)


- time needed to reach the bottom of a document, which seems to be 
discussed in the context of OS X only. This may be Qt-version related.


I think Pavel Sanda listed also one recent change related to X11 (Linux 
and cousins).


Best regards,

O.

Re: Qt: was Slow scrolling

[Jean-Marc Lasgouttes]

Le 05/01/2012 02:40, André Pönitz a écrit :

The main performance problems I have seesn so far are due to an abuse of
the toolkit, not caused _by_ the toolkit (except for the remote raster
painter problem perhaps). Just start at RowPainter::paintChars() and
walk down through all the mess _before_ it actually hits Qt's drawText()
It is slow? You bet.


The question is whether the Xorg takes 90% cpu complaints will go away 
with Abdel new patch. If they don't, it means that there are some slow 
operations on the Qt side that we do not understand (i.e. things we 
should avoid to use). I am not sure that our code in 
rowPainter::paintChars is so costly (except the fact that all 
metrics/painting should be done word-wise) I do not remember it showing 
so high in profiler. I'll have to check again some day.


JMarc

Re: Qt: was Slow scrolling

[Jean-Marc Lasgouttes]

Le 05/01/2012 09:40, Olivier Ripoll a écrit :

On 05.01.2012 05:16, Jerry wrote:

Do the developers monitor this list? Or does someone need to file a
bug report for the slow scrolling problem?

Jerry


Yes, they are looking at it. If you look at the thread, you'll see
several names of LyX developers (not exhautively: Pavel Sanda, Richard
Heck, Jean-Marc Lasgouttes, André Pönitz)


The problem is that we have yet to pinpoint the root cause. I see two 
major points:


- we have experimental code that seems to improve the situation on 
linux. We'll probably learn more once it is deployed to many people. I 
am not sure there are plans to port to branch yet. This may be useful 
for cases where different people see different speeds.


- there is a part of the code that we know should be rewritten: to 
compute metrics (size of words), we work at glyph level, while painting 
is done at word level. This is what creates display problems with OS X 
when the is kerning/ligatures effects. The paint single char pref that 
has been discussed makes everything work at glyph level, which is 
correct but slow. What we need is to do all at word level (except for 
RtL text, which is a different story). Unfortunately, this part of code 
is a can of worm and nobody dares touching it.


JMarc

Re: Qt: was Slow scrolling

[Rainer M Krug]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/01/12 10:58, Jean-Marc Lasgouttes wrote:
 Le 05/01/2012 09:40, Olivier Ripoll a écrit :
 On 05.01.2012 05:16, Jerry wrote:
 Do the developers monitor this list? Or does someone need to
 file a bug report for the slow scrolling problem?
 
 Jerry
 
 Yes, they are looking at it. If you look at the thread, you'll
 see several names of LyX developers (not exhautively: Pavel
 Sanda, Richard Heck, Jean-Marc Lasgouttes, André Pönitz)
 
 The problem is that we have yet to pinpoint the root cause. I see
 two major points:
 
 - we have experimental code that seems to improve the situation on 
 linux. We'll probably learn more once it is deployed to many
 people. I am not sure there are plans to port to branch yet. This
 may be useful for cases where different people see different
 speeds.
 
 - there is a part of the code that we know should be rewritten: to 
 compute metrics (size of words), we work at glyph level, while
 painting is done at word level. This is what creates display
 problems with OS X when the is kerning/ligatures effects. The
 paint single char pref that has been discussed makes everything
 work at glyph level, which is correct but slow. What we need is to
 do all at word level (except for RtL text, which is a different
 story). Unfortunately, this part of code is a can of worm and
 nobody dares touching it.

If I look at the number of emails flying around on this issue, one
should look at options how this can be fixed. I must admit I do not
know the inner workings of LyX, so I might be completely off.

I nobody dares to touch this code (I would guess because of time
requirements once one starts fixing it), one could try to raise funds
to pay somebody (preferably somebody who knows LyX's inner workings)
to address this issue - it seems to be on many peoples mind.

Cheers,

Rainer


 
 JMarc


- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8FeLcACgkQoYgNqgF2egqWJwCfaqqoP9Rxzs8J1ZK8tgqLCW5M
Y4UAn0u47pmpgS3fYORvbt+J0u3AWTS3
=N3hn
-END PGP SIGNATURE-

Re: Qt: was Slow scrolling

[Murat Yildizoglu]

I would like to see the problem on other computers. In my case (I hope that
you have received the video I have sent), I would rather prefer the
developers to work on more fundamental issues, I am happy with what I have
(I can only state on my case before seing the videos of others) ;-)

Murat

2012/1/5 Rainer M Krug r.m.k...@gmail.com

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 05/01/12 10:58, Jean-Marc Lasgouttes wrote:
  Le 05/01/2012 09:40, Olivier Ripoll a écrit :
  On 05.01.2012 05:16, Jerry wrote:
  Do the developers monitor this list? Or does someone need to
  file a bug report for the slow scrolling problem?
 
  Jerry
 
  Yes, they are looking at it. If you look at the thread, you'll
  see several names of LyX developers (not exhautively: Pavel
  Sanda, Richard Heck, Jean-Marc Lasgouttes, André Pönitz)
 
  The problem is that we have yet to pinpoint the root cause. I see
  two major points:
 
  - we have experimental code that seems to improve the situation on
  linux. We'll probably learn more once it is deployed to many
  people. I am not sure there are plans to port to branch yet. This
  may be useful for cases where different people see different
  speeds.
 
  - there is a part of the code that we know should be rewritten: to
  compute metrics (size of words), we work at glyph level, while
  painting is done at word level. This is what creates display
  problems with OS X when the is kerning/ligatures effects. The
  paint single char pref that has been discussed makes everything
  work at glyph level, which is correct but slow. What we need is to
  do all at word level (except for RtL text, which is a different
  story). Unfortunately, this part of code is a can of worm and
  nobody dares touching it.

 If I look at the number of emails flying around on this issue, one
 should look at options how this can be fixed. I must admit I do not
 know the inner workings of LyX, so I might be completely off.

 I nobody dares to touch this code (I would guess because of time
 requirements once one starts fixing it), one could try to raise funds
 to pay somebody (preferably somebody who knows LyX's inner workings)
 to address this issue - it seems to be on many peoples mind.

 Cheers,

 Rainer


 
  JMarc


 - --
 Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
 Biology, UCT), Dipl. Phys. (Germany)

 Centre of Excellence for Invasion Biology
 Stellenbosch University
 South Africa

 Tel :   +33 - (0)9 53 10 27 44
 Cell:   +33 - (0)6 85 62 59 98
 Fax :   +33 - (0)9 58 10 27 44

 Fax (D):+49 - (0)3 21 21 25 22 44

 email:  rai...@krugs.de

 Skype:  RMkrug
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk8FeLcACgkQoYgNqgF2egqWJwCfaqqoP9Rxzs8J1ZK8tgqLCW5M
 Y4UAn0u47pmpgS3fYORvbt+J0u3AWTS3
 =N3hn
 -END PGP SIGNATURE-




-- 
Prof. Murat Yildizoglu

Université Montesquieu Bordeaux IV
GREThA (UMR CNRS 5113)
Avenue Léon Duguit
33608 Pessac cedex
France

Bureau : F-331

yi...@u-bordeaux4.fr

http://yildizoglu.info

http://www.twitter.com/yildizoglu

Re: Qt: was Slow scrolling

[Richard Heck]

On 01/05/2012 05:17 AM, Rainer M Krug wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/01/12 10:58, Jean-Marc Lasgouttes wrote:

Le 05/01/2012 09:40, Olivier Ripoll a écrit :

On 05.01.2012 05:16, Jerry wrote:

Do the developers monitor this list? Or does someone need to
file a bug report for the slow scrolling problem?

Jerry

Yes, they are looking at it. If you look at the thread, you'll
see several names of LyX developers (not exhautively: Pavel
Sanda, Richard Heck, Jean-Marc Lasgouttes, André Pönitz)

The problem is that we have yet to pinpoint the root cause. I see
two major points:

- we have experimental code that seems to improve the situation on
linux. We'll probably learn more once it is deployed to many
people. I am not sure there are plans to port to branch yet. This
may be useful for cases where different people see different
speeds.

- there is a part of the code that we know should be rewritten: to
compute metrics (size of words), we work at glyph level, while
painting is done at word level. This is what creates display
problems with OS X when the is kerning/ligatures effects. The
paint single char pref that has been discussed makes everything
work at glyph level, which is correct but slow. What we need is to
do all at word level (except for RtL text, which is a different
story). Unfortunately, this part of code is a can of worm and
nobody dares touching it.

If I look at the number of emails flying around on this issue, one
should look at options how this can be fixed. I must admit I do not
know the inner workings of LyX, so I might be completely off.

I nobody dares to touch this code (I would guess because of time
requirements once one starts fixing it), one could try to raise funds
to pay somebody (preferably somebody who knows LyX's inner workings)
to address this issue - it seems to be on many peoples mind.
I think it's more of an issue of pure fear. That code is extremely 
complicated, and it would be very easy to mess things up worse instead 
of fixing them. So, speaking as branch maintainer, that kind of re-write 
definitely isn't happening in the 2.0.x series.


Richard

Re: Qt: was Slow scrolling

[Olivier Ripoll]

On 05.01.2012 05:16, Jerry wrote:

Do the developers monitor this list? Or does someone need to file a bug report 
for the slow scrolling problem?

Jerry


Yes, they are looking at it. If you look at the thread, you'll see 
several names of LyX developers (not exhautively: Pavel Sanda, Richard 
Heck, Jean-Marc Lasgouttes, André Pönitz)


As for the bug report, I ave the impression there are 2 bugs reported in 
the thread under the slow scrolling umbrella:


- high CPU usage and jumpy scrolling (versus smooth), as you reported in 
your message, which is what I observe also. Seems unrealetd to the OS, 
as you are on OS X, I'm on Windows 7. This bug may also be multiple 
ones, as you mention 2.0.1 also has issues while it is flawless for me 
(I do not think it is Qt-version related)


- time needed to reach the bottom of a document, which seems to be 
discussed in the context of OS X only. This may be Qt-version related.


I think Pavel Sanda listed also one recent change related to X11 (Linux 
and cousins).


Best regards,

O.

Re: Qt: was Slow scrolling

[Jean-Marc Lasgouttes]

Le 05/01/2012 02:40, André Pönitz a écrit :

The main performance problems I have seesn so far are due to an abuse of
the toolkit, not caused _by_ the toolkit (except for the remote raster
painter problem perhaps). Just start at RowPainter::paintChars() and
walk down through all the mess _before_ it actually hits Qt's drawText()
It is slow? You bet.


The question is whether the Xorg takes 90% cpu complaints will go away 
with Abdel new patch. If they don't, it means that there are some slow 
operations on the Qt side that we do not understand (i.e. things we 
should avoid to use). I am not sure that our code in 
rowPainter::paintChars is so costly (except the fact that all 
metrics/painting should be done word-wise) I do not remember it showing 
so high in profiler. I'll have to check again some day.


JMarc

Re: Qt: was Slow scrolling

[Jean-Marc Lasgouttes]

Le 05/01/2012 09:40, Olivier Ripoll a écrit :

On 05.01.2012 05:16, Jerry wrote:

Do the developers monitor this list? Or does someone need to file a
bug report for the slow scrolling problem?

Jerry


Yes, they are looking at it. If you look at the thread, you'll see
several names of LyX developers (not exhautively: Pavel Sanda, Richard
Heck, Jean-Marc Lasgouttes, André Pönitz)


The problem is that we have yet to pinpoint the root cause. I see two 
major points:


- we have experimental code that seems to improve the situation on 
linux. We'll probably learn more once it is deployed to many people. I 
am not sure there are plans to port to branch yet. This may be useful 
for cases where different people see different speeds.


- there is a part of the code that we know should be rewritten: to 
compute metrics (size of words), we work at glyph level, while painting 
is done at word level. This is what creates display problems with OS X 
when the is kerning/ligatures effects. The paint single char pref that 
has been discussed makes everything work at glyph level, which is 
correct but slow. What we need is to do all at word level (except for 
RtL text, which is a different story). Unfortunately, this part of code 
is a can of worm and nobody dares touching it.


JMarc

Re: Qt: was Slow scrolling

[Rainer M Krug]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/01/12 10:58, Jean-Marc Lasgouttes wrote:
 Le 05/01/2012 09:40, Olivier Ripoll a écrit :
 On 05.01.2012 05:16, Jerry wrote:
 Do the developers monitor this list? Or does someone need to
 file a bug report for the slow scrolling problem?
 
 Jerry
 
 Yes, they are looking at it. If you look at the thread, you'll
 see several names of LyX developers (not exhautively: Pavel
 Sanda, Richard Heck, Jean-Marc Lasgouttes, André Pönitz)
 
 The problem is that we have yet to pinpoint the root cause. I see
 two major points:
 
 - we have experimental code that seems to improve the situation on 
 linux. We'll probably learn more once it is deployed to many
 people. I am not sure there are plans to port to branch yet. This
 may be useful for cases where different people see different
 speeds.
 
 - there is a part of the code that we know should be rewritten: to 
 compute metrics (size of words), we work at glyph level, while
 painting is done at word level. This is what creates display
 problems with OS X when the is kerning/ligatures effects. The
 paint single char pref that has been discussed makes everything
 work at glyph level, which is correct but slow. What we need is to
 do all at word level (except for RtL text, which is a different
 story). Unfortunately, this part of code is a can of worm and
 nobody dares touching it.

If I look at the number of emails flying around on this issue, one
should look at options how this can be fixed. I must admit I do not
know the inner workings of LyX, so I might be completely off.

I nobody dares to touch this code (I would guess because of time
requirements once one starts fixing it), one could try to raise funds
to pay somebody (preferably somebody who knows LyX's inner workings)
to address this issue - it seems to be on many peoples mind.

Cheers,

Rainer


 
 JMarc


- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8FeLcACgkQoYgNqgF2egqWJwCfaqqoP9Rxzs8J1ZK8tgqLCW5M
Y4UAn0u47pmpgS3fYORvbt+J0u3AWTS3
=N3hn
-END PGP SIGNATURE-

Re: Qt: was Slow scrolling

[Murat Yildizoglu]

I would like to see the problem on other computers. In my case (I hope that
you have received the video I have sent), I would rather prefer the
developers to work on more fundamental issues, I am happy with what I have
(I can only state on my case before seing the videos of others) ;-)

Murat

2012/1/5 Rainer M Krug r.m.k...@gmail.com

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 05/01/12 10:58, Jean-Marc Lasgouttes wrote:
  Le 05/01/2012 09:40, Olivier Ripoll a écrit :
  On 05.01.2012 05:16, Jerry wrote:
  Do the developers monitor this list? Or does someone need to
  file a bug report for the slow scrolling problem?
 
  Jerry
 
  Yes, they are looking at it. If you look at the thread, you'll
  see several names of LyX developers (not exhautively: Pavel
  Sanda, Richard Heck, Jean-Marc Lasgouttes, André Pönitz)
 
  The problem is that we have yet to pinpoint the root cause. I see
  two major points:
 
  - we have experimental code that seems to improve the situation on
  linux. We'll probably learn more once it is deployed to many
  people. I am not sure there are plans to port to branch yet. This
  may be useful for cases where different people see different
  speeds.
 
  - there is a part of the code that we know should be rewritten: to
  compute metrics (size of words), we work at glyph level, while
  painting is done at word level. This is what creates display
  problems with OS X when the is kerning/ligatures effects. The
  paint single char pref that has been discussed makes everything
  work at glyph level, which is correct but slow. What we need is to
  do all at word level (except for RtL text, which is a different
  story). Unfortunately, this part of code is a can of worm and
  nobody dares touching it.

 If I look at the number of emails flying around on this issue, one
 should look at options how this can be fixed. I must admit I do not
 know the inner workings of LyX, so I might be completely off.

 I nobody dares to touch this code (I would guess because of time
 requirements once one starts fixing it), one could try to raise funds
 to pay somebody (preferably somebody who knows LyX's inner workings)
 to address this issue - it seems to be on many peoples mind.

 Cheers,

 Rainer


 
  JMarc


 - --
 Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
 Biology, UCT), Dipl. Phys. (Germany)

 Centre of Excellence for Invasion Biology
 Stellenbosch University
 South Africa

 Tel :   +33 - (0)9 53 10 27 44
 Cell:   +33 - (0)6 85 62 59 98
 Fax :   +33 - (0)9 58 10 27 44

 Fax (D):+49 - (0)3 21 21 25 22 44

 email:  rai...@krugs.de

 Skype:  RMkrug
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk8FeLcACgkQoYgNqgF2egqWJwCfaqqoP9Rxzs8J1ZK8tgqLCW5M
 Y4UAn0u47pmpgS3fYORvbt+J0u3AWTS3
 =N3hn
 -END PGP SIGNATURE-




-- 
Prof. Murat Yildizoglu

Université Montesquieu Bordeaux IV
GREThA (UMR CNRS 5113)
Avenue Léon Duguit
33608 Pessac cedex
France

Bureau : F-331

yi...@u-bordeaux4.fr

http://yildizoglu.info

http://www.twitter.com/yildizoglu

Re: Qt: was Slow scrolling

[Richard Heck]

On 01/05/2012 05:17 AM, Rainer M Krug wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/01/12 10:58, Jean-Marc Lasgouttes wrote:

Le 05/01/2012 09:40, Olivier Ripoll a écrit :

On 05.01.2012 05:16, Jerry wrote:

Do the developers monitor this list? Or does someone need to
file a bug report for the slow scrolling problem?

Jerry

Yes, they are looking at it. If you look at the thread, you'll
see several names of LyX developers (not exhautively: Pavel
Sanda, Richard Heck, Jean-Marc Lasgouttes, André Pönitz)

The problem is that we have yet to pinpoint the root cause. I see
two major points:

- we have experimental code that seems to improve the situation on
linux. We'll probably learn more once it is deployed to many
people. I am not sure there are plans to port to branch yet. This
may be useful for cases where different people see different
speeds.

- there is a part of the code that we know should be rewritten: to
compute metrics (size of words), we work at glyph level, while
painting is done at word level. This is what creates display
problems with OS X when the is kerning/ligatures effects. The
paint single char pref that has been discussed makes everything
work at glyph level, which is correct but slow. What we need is to
do all at word level (except for RtL text, which is a different
story). Unfortunately, this part of code is a can of worm and
nobody dares touching it.

If I look at the number of emails flying around on this issue, one
should look at options how this can be fixed. I must admit I do not
know the inner workings of LyX, so I might be completely off.

I nobody dares to touch this code (I would guess because of time
requirements once one starts fixing it), one could try to raise funds
to pay somebody (preferably somebody who knows LyX's inner workings)
to address this issue - it seems to be on many peoples mind.
I think it's more of an issue of pure fear. That code is extremely 
complicated, and it would be very easy to mess things up worse instead 
of fixing them. So, speaking as branch maintainer, that kind of re-write 
definitely isn't happening in the 2.0.x series.


Richard

Re: Qt: was Slow scrolling

[Olivier Ripoll]

On 05.01.2012 05:16, Jerry wrote:

Do the developers monitor this list? Or does someone need to file a bug report 
for the slow scrolling problem?

Jerry


Yes, they are looking at it. If you look at the thread, you'll see 
several names of LyX developers (not exhautively: Pavel Sanda, Richard 
Heck, Jean-Marc Lasgouttes, André Pönitz)


As for the bug report, I ave the impression there are 2 bugs reported in 
the thread under the "slow scrolling" umbrella:


- high CPU usage and jumpy scrolling (versus smooth), as you reported in 
your message, which is what I observe also. Seems unrealetd to the OS, 
as you are on OS X, I'm on Windows 7. This bug may also be multiple 
ones, as you mention 2.0.1 also has issues while it is flawless for me 
(I do not think it is Qt-version related)


- time needed to reach the bottom of a document, which seems to be 
discussed in the context of OS X only. This may be Qt-version related.


I think Pavel Sanda listed also one recent change related to X11 (Linux 
and cousins).


Best regards,

O.

Re: Qt: was Slow scrolling

[Jean-Marc Lasgouttes]

Le 05/01/2012 02:40, André Pönitz a écrit :

The main performance problems I have seesn so far are due to an abuse of
the toolkit, not caused _by_ the toolkit (except for the remote raster
painter problem perhaps). Just start at RowPainter::paintChars() and
walk down through all the mess _before_ it actually hits Qt's drawText()
It is slow? You bet.


The question is whether the "Xorg takes 90% cpu" complaints will go away 
with Abdel new patch. If they don't, it means that there are some slow 
operations on the Qt side that we do not understand (i.e. things we 
should avoid to use). I am not sure that our code in 
rowPainter::paintChars is so costly (except the fact that all 
metrics/painting should be done word-wise) I do not remember it showing 
so high in profiler. I'll have to check again some day.


JMarc

Re: Qt: was Slow scrolling

[Jean-Marc Lasgouttes]

Le 05/01/2012 09:40, Olivier Ripoll a écrit :

On 05.01.2012 05:16, Jerry wrote:

Do the developers monitor this list? Or does someone need to file a
bug report for the slow scrolling problem?

Jerry


Yes, they are looking at it. If you look at the thread, you'll see
several names of LyX developers (not exhautively: Pavel Sanda, Richard
Heck, Jean-Marc Lasgouttes, André Pönitz)


The problem is that we have yet to pinpoint the root cause. I see two 
major points:


- we have experimental code that seems to improve the situation on 
linux. We'll probably learn more once it is deployed to many people. I 
am not sure there are plans to port to branch yet. This may be useful 
for cases where different people see different speeds.


- there is a part of the code that we know should be rewritten: to 
compute metrics (size of words), we work at glyph level, while painting 
is done at word level. This is what creates display problems with OS X 
when the is kerning/ligatures effects. The "paint single char" pref that 
has been discussed makes everything work at glyph level, which is 
correct but slow. What we need is to do all at word level (except for 
RtL text, which is a different story). Unfortunately, this part of code 
is a can of worm and nobody dares touching it.


JMarc

Re: Qt: was Slow scrolling

[Rainer M Krug]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/01/12 10:58, Jean-Marc Lasgouttes wrote:
> Le 05/01/2012 09:40, Olivier Ripoll a écrit :
>> On 05.01.2012 05:16, Jerry wrote:
>>> Do the developers monitor this list? Or does someone need to
>>> file a bug report for the slow scrolling problem?
>>> 
>>> Jerry
>> 
>> Yes, they are looking at it. If you look at the thread, you'll
>> see several names of LyX developers (not exhautively: Pavel
>> Sanda, Richard Heck, Jean-Marc Lasgouttes, André Pönitz)
> 
> The problem is that we have yet to pinpoint the root cause. I see
> two major points:
> 
> - we have experimental code that seems to improve the situation on 
> linux. We'll probably learn more once it is deployed to many
> people. I am not sure there are plans to port to branch yet. This
> may be useful for cases where different people see different
> speeds.
> 
> - there is a part of the code that we know should be rewritten: to 
> compute metrics (size of words), we work at glyph level, while
> painting is done at word level. This is what creates display
> problems with OS X when the is kerning/ligatures effects. The
> "paint single char" pref that has been discussed makes everything
> work at glyph level, which is correct but slow. What we need is to
> do all at word level (except for RtL text, which is a different
> story). Unfortunately, this part of code is a can of worm and
> nobody dares touching it.

If I look at the number of emails flying around on this issue, one
should look at options how this can be fixed. I must admit I do not
know the inner workings of LyX, so I might be completely off.

I nobody dares to touch this code (I would guess because of time
requirements once one starts fixing it), one could try to raise funds
to pay somebody (preferably somebody who knows LyX's inner workings)
to address this issue - it seems to be on many peoples mind.

Cheers,

Rainer


> 
> JMarc


- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8FeLcACgkQoYgNqgF2egqWJwCfaqqoP9Rxzs8J1ZK8tgqLCW5M
Y4UAn0u47pmpgS3fYORvbt+J0u3AWTS3
=N3hn
-END PGP SIGNATURE-

Re: Qt: was Slow scrolling

[Murat Yildizoglu]

I would like to see the problem on other computers. In my case (I hope that
you have received the video I have sent), I would rather prefer the
developers to work on more fundamental issues, I am happy with what I have
(I can only state on my case before seing the videos of others) ;-)

Murat

2012/1/5 Rainer M Krug 

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/01/12 10:58, Jean-Marc Lasgouttes wrote:
> > Le 05/01/2012 09:40, Olivier Ripoll a écrit :
> >> On 05.01.2012 05:16, Jerry wrote:
> >>> Do the developers monitor this list? Or does someone need to
> >>> file a bug report for the slow scrolling problem?
> >>>
> >>> Jerry
> >>
> >> Yes, they are looking at it. If you look at the thread, you'll
> >> see several names of LyX developers (not exhautively: Pavel
> >> Sanda, Richard Heck, Jean-Marc Lasgouttes, André Pönitz)
> >
> > The problem is that we have yet to pinpoint the root cause. I see
> > two major points:
> >
> > - we have experimental code that seems to improve the situation on
> > linux. We'll probably learn more once it is deployed to many
> > people. I am not sure there are plans to port to branch yet. This
> > may be useful for cases where different people see different
> > speeds.
> >
> > - there is a part of the code that we know should be rewritten: to
> > compute metrics (size of words), we work at glyph level, while
> > painting is done at word level. This is what creates display
> > problems with OS X when the is kerning/ligatures effects. The
> > "paint single char" pref that has been discussed makes everything
> > work at glyph level, which is correct but slow. What we need is to
> > do all at word level (except for RtL text, which is a different
> > story). Unfortunately, this part of code is a can of worm and
> > nobody dares touching it.
>
> If I look at the number of emails flying around on this issue, one
> should look at options how this can be fixed. I must admit I do not
> know the inner workings of LyX, so I might be completely off.
>
> I nobody dares to touch this code (I would guess because of time
> requirements once one starts fixing it), one could try to raise funds
> to pay somebody (preferably somebody who knows LyX's inner workings)
> to address this issue - it seems to be on many peoples mind.
>
> Cheers,
>
> Rainer
>
>
> >
> > JMarc
>
>
> - --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
> Biology, UCT), Dipl. Phys. (Germany)
>
> Centre of Excellence for Invasion Biology
> Stellenbosch University
> South Africa
>
> Tel :   +33 - (0)9 53 10 27 44
> Cell:   +33 - (0)6 85 62 59 98
> Fax :   +33 - (0)9 58 10 27 44
>
> Fax (D):+49 - (0)3 21 21 25 22 44
>
> email:  rai...@krugs.de
>
> Skype:  RMkrug
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk8FeLcACgkQoYgNqgF2egqWJwCfaqqoP9Rxzs8J1ZK8tgqLCW5M
> Y4UAn0u47pmpgS3fYORvbt+J0u3AWTS3
> =N3hn
> -END PGP SIGNATURE-
>



-- 
Prof. Murat Yildizoglu

Université Montesquieu Bordeaux IV
GREThA (UMR CNRS 5113)
Avenue Léon Duguit
33608 Pessac cedex
France

Bureau : F-331

yi...@u-bordeaux4.fr

http://yildizoglu.info

http://www.twitter.com/yildizoglu

Re: Qt: was Slow scrolling

[Richard Heck]

On 01/05/2012 05:17 AM, Rainer M Krug wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/01/12 10:58, Jean-Marc Lasgouttes wrote:

Le 05/01/2012 09:40, Olivier Ripoll a écrit :

On 05.01.2012 05:16, Jerry wrote:

Do the developers monitor this list? Or does someone need to
file a bug report for the slow scrolling problem?

Jerry

Yes, they are looking at it. If you look at the thread, you'll
see several names of LyX developers (not exhautively: Pavel
Sanda, Richard Heck, Jean-Marc Lasgouttes, André Pönitz)

The problem is that we have yet to pinpoint the root cause. I see
two major points:

- we have experimental code that seems to improve the situation on
linux. We'll probably learn more once it is deployed to many
people. I am not sure there are plans to port to branch yet. This
may be useful for cases where different people see different
speeds.

- there is a part of the code that we know should be rewritten: to
compute metrics (size of words), we work at glyph level, while
painting is done at word level. This is what creates display
problems with OS X when the is kerning/ligatures effects. The
"paint single char" pref that has been discussed makes everything
work at glyph level, which is correct but slow. What we need is to
do all at word level (except for RtL text, which is a different
story). Unfortunately, this part of code is a can of worm and
nobody dares touching it.

If I look at the number of emails flying around on this issue, one
should look at options how this can be fixed. I must admit I do not
know the inner workings of LyX, so I might be completely off.

I nobody dares to touch this code (I would guess because of time
requirements once one starts fixing it), one could try to raise funds
to pay somebody (preferably somebody who knows LyX's inner workings)
to address this issue - it seems to be on many peoples mind.
I think it's more of an issue of pure fear. That code is extremely 
complicated, and it would be very easy to mess things up worse instead 
of fixing them. So, speaking as branch maintainer, that kind of re-write 
definitely isn't happening in the 2.0.x series.


Richard

Re: Qt: was Slow scrolling

[André Pönitz]

On Wed, Jan 04, 2012 at 05:19:02PM -0500, Steve Litt wrote:
 On Tuesday, January 03, 2012 03:36:16 PM Stephan Witt wrote:
  Am 03.01.2012 um 17:15 schrieb Olivier Ripoll:
 
   Hi,
   
   Check my 2 messages in the LyX 2.0.2 Released thread, one dated
   december 5th (user mailing lists, perhaps devel too) and the
   other one dated december 16th (devel ML), which contains more
   details:
   
   http://www.mail-archive.com/lyx-users@lists.lyx.org/msg90218.html
   http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg172462.htm
   l
  
  Hi,
  
  I'm almost sure it depends on Qt-Version.
  
  With LyX on Mac with Qt4 we have two fundamental problems:
 
 At the risk of sounding like a broken record, if Qt continues to 
 produce these types of problems, isn't there different library or 
 combination of libraries the developers can use?

At the risk of sounding like a broken record: Some of the issues in the
past have been caused by wrong usage within LyX (like repaint() instead
of update()), and some by insisting to use Qt versions that have been
released before the other components in the system, like newer versions
of MacOSX. I just run svn up and README says The Qt4 library, at least
version 4.2.2. For all features newer versions (e.g. Qt 4.6) are
recommended. _Please_? That was state of the art in _2006_?

That is not to say that Qt is flawless, Enrico(?)'s execvp/exeve
issue for instance. But the thing _is_ open source, too, so if it's
a pain point, fix it.

 Back when I wrote my why oh why did you dump xforms rant, it seemed 
 like maybe the compile problems were just growing pains from Qt going 
 from version 3 to version 4. But now it's years later, and we're still 
 hearing (I paraphrase) the quality of your LyX program depends on 
 your Qt version.
 
 I know, you've told me before, Qt does a lot of busywork and makes 
 programming LyX much simpler. It handles all the localization, etc. 
 Programming LyX without Qt would be a horrendeous chore.
 
 But is Qt really doing you a favor when certain Qt versions make your 
 program perform badly?

*gosh*

The main performance problems I have seesn so far are due to an abuse of
the toolkit, not caused _by_ the toolkit (except for the remote raster
painter problem perhaps). Just start at RowPainter::paintChars() and
walk down through all the mess _before_ it actually hits Qt's drawText()
It is slow? You bet.

 The LyX developers work so hard to create a 
 robust, high productivity program, only to have a tool vendor snatch 
 defeat from the jaws of victory. Isn't there another localization 
 library you can use, and another GUI library, and whatever?

Which one do you think would do the trick for Window, Mac _and_ Linux?
 
 Thanks

Please backport LyX to xforms. There was even a new release 1.0.93
in May 2010. If you have done it, and it loads the UserGuide I'll
shut up for eternity on that topic.

Andre'

Re: Qt: was Slow scrolling

[Stephan Witt]

Am 05.01.2012 um 02:40 schrieb André Pönitz:

 On Wed, Jan 04, 2012 at 05:19:02PM -0500, Steve Litt wrote:
 On Tuesday, January 03, 2012 03:36:16 PM Stephan Witt wrote:
 Am 03.01.2012 um 17:15 schrieb Olivier Ripoll:
 
 Hi,
 
 Check my 2 messages in the LyX 2.0.2 Released thread, one dated
 december 5th (user mailing lists, perhaps devel too) and the
 other one dated december 16th (devel ML), which contains more
 details:
 
 http://www.mail-archive.com/lyx-users@lists.lyx.org/msg90218.html
 http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg172462.htm
 l
 
 Hi,
 
 I'm almost sure it depends on Qt-Version.
 
 With LyX on Mac with Qt4 we have two fundamental problems:
 
 At the risk of sounding like a broken record, if Qt continues to 
 produce these types of problems, isn't there different library or 
 combination of libraries the developers can use?
 
 At the risk of sounding like a broken record: Some of the issues in the
 past have been caused by wrong usage within LyX (like repaint() instead
 of update()), and some by insisting to use Qt versions that have been
 released before the other components in the system, like newer versions
 of MacOSX. I just run svn up and README says The Qt4 library, at least
 version 4.2.2. For all features newer versions (e.g. Qt 4.6) are
 recommended. _Please_? That was state of the art in _2006_?
 
 That is not to say that Qt is flawless, Enrico(?)'s execvp/exeve
 issue for instance. But the thing _is_ open source, too, so if it's
 a pain point, fix it.

I second that. At the time of the move to Qt-exclusive it was debatable.
Now this isn't possible anymore. And Qt is an excellent toolkit.

 
 Back when I wrote my why oh why did you dump xforms rant, it seemed 
 like maybe the compile problems were just growing pains from Qt going 
 from version 3 to version 4. But now it's years later, and we're still 
 hearing (I paraphrase) the quality of your LyX program depends on 
 your Qt version.
 
 I know, you've told me before, Qt does a lot of busywork and makes 
 programming LyX much simpler. It handles all the localization, etc. 
 Programming LyX without Qt would be a horrendeous chore.
 
 But is Qt really doing you a favor when certain Qt versions make your 
 program perform badly?
 
 *gosh*
 
 The main performance problems I have seen so far are due to an abuse of
 the toolkit, not caused _by_ the toolkit (except for the remote raster
 painter problem perhaps). Just start at RowPainter::paintChars() and
 walk down through all the mess _before_ it actually hits Qt's drawText()
 It is slow? You bet.

Note, I've said: we have (aka LyX code has) a problem. 
This isn't easy to change - and we all do it in our spare time.
Everything around is a moving target - the OS and the Qt library.
And it isn't possible for every move to avoid drawbacks for the late comer.

For the painting problems: it started with broken ligature drawing and
the (re)action of LyX coders was a hack (split the text drawing at the letter 
'f'). 
As support for kerning for on-screen drawing was added (Qt 4.7 AFAIK) the 
consequence
was to split at every character. Obviously a rework of the painter/cursor 
movement
code is a much better action... but someone (who gets no money for this) has to 
do the job.
I had a look into this and decided I cannot afford that. I have a real live too.

All in all André is right: it's not the toolkit Qt, it's the use of it.

Stephan

Re: Qt: was Slow scrolling

[Stephan Witt]

Am 05.01.2012 um 05:16 schrieb Jerry:

 Do the developers monitor this list?

I think so.

 Or does someone need to file a bug report for the slow scrolling problem?

Perhaps. But ATM there is no problem description to reproduce it, AFAICS.
Some users have a problem only on Lion - you have it on Snow Leopard (SL) too.
I see no problem here on my system (SL) - perhaps I have lower requirements.

Stephan

Re: Qt: was Slow scrolling

[Jerry]

On Jan 4, 2012, at 11:36 PM, Stephan Witt wrote:

 Am 05.01.2012 um 05:16 schrieb Jerry:
 
 Do the developers monitor this list?
 
 I think so.
 
 Or does someone need to file a bug report for the slow scrolling problem?
 
 Perhaps. But ATM there is no problem description to reproduce it, AFAICS.
 Some users have a problem only on Lion - you have it on Snow Leopard (SL) too.
 I see no problem here on my system (SL) - perhaps I have lower requirements.
 
 Stephan

BTW, thanks for your help. I gather that you're the person who builds the Mac 
binaries.

Jerry

Re: Qt: was Slow scrolling

[André Pönitz]

On Wed, Jan 04, 2012 at 05:19:02PM -0500, Steve Litt wrote:
 On Tuesday, January 03, 2012 03:36:16 PM Stephan Witt wrote:
  Am 03.01.2012 um 17:15 schrieb Olivier Ripoll:
 
   Hi,
   
   Check my 2 messages in the LyX 2.0.2 Released thread, one dated
   december 5th (user mailing lists, perhaps devel too) and the
   other one dated december 16th (devel ML), which contains more
   details:
   
   http://www.mail-archive.com/lyx-users@lists.lyx.org/msg90218.html
   http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg172462.htm
   l
  
  Hi,
  
  I'm almost sure it depends on Qt-Version.
  
  With LyX on Mac with Qt4 we have two fundamental problems:
 
 At the risk of sounding like a broken record, if Qt continues to 
 produce these types of problems, isn't there different library or 
 combination of libraries the developers can use?

At the risk of sounding like a broken record: Some of the issues in the
past have been caused by wrong usage within LyX (like repaint() instead
of update()), and some by insisting to use Qt versions that have been
released before the other components in the system, like newer versions
of MacOSX. I just run svn up and README says The Qt4 library, at least
version 4.2.2. For all features newer versions (e.g. Qt 4.6) are
recommended. _Please_? That was state of the art in _2006_?

That is not to say that Qt is flawless, Enrico(?)'s execvp/exeve
issue for instance. But the thing _is_ open source, too, so if it's
a pain point, fix it.

 Back when I wrote my why oh why did you dump xforms rant, it seemed 
 like maybe the compile problems were just growing pains from Qt going 
 from version 3 to version 4. But now it's years later, and we're still 
 hearing (I paraphrase) the quality of your LyX program depends on 
 your Qt version.
 
 I know, you've told me before, Qt does a lot of busywork and makes 
 programming LyX much simpler. It handles all the localization, etc. 
 Programming LyX without Qt would be a horrendeous chore.
 
 But is Qt really doing you a favor when certain Qt versions make your 
 program perform badly?

*gosh*

The main performance problems I have seesn so far are due to an abuse of
the toolkit, not caused _by_ the toolkit (except for the remote raster
painter problem perhaps). Just start at RowPainter::paintChars() and
walk down through all the mess _before_ it actually hits Qt's drawText()
It is slow? You bet.

 The LyX developers work so hard to create a 
 robust, high productivity program, only to have a tool vendor snatch 
 defeat from the jaws of victory. Isn't there another localization 
 library you can use, and another GUI library, and whatever?

Which one do you think would do the trick for Window, Mac _and_ Linux?
 
 Thanks

Please backport LyX to xforms. There was even a new release 1.0.93
in May 2010. If you have done it, and it loads the UserGuide I'll
shut up for eternity on that topic.

Andre'

Re: Qt: was Slow scrolling

[Stephan Witt]

Am 05.01.2012 um 02:40 schrieb André Pönitz:

 On Wed, Jan 04, 2012 at 05:19:02PM -0500, Steve Litt wrote:
 On Tuesday, January 03, 2012 03:36:16 PM Stephan Witt wrote:
 Am 03.01.2012 um 17:15 schrieb Olivier Ripoll:
 
 Hi,
 
 Check my 2 messages in the LyX 2.0.2 Released thread, one dated
 december 5th (user mailing lists, perhaps devel too) and the
 other one dated december 16th (devel ML), which contains more
 details:
 
 http://www.mail-archive.com/lyx-users@lists.lyx.org/msg90218.html
 http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg172462.htm
 l
 
 Hi,
 
 I'm almost sure it depends on Qt-Version.
 
 With LyX on Mac with Qt4 we have two fundamental problems:
 
 At the risk of sounding like a broken record, if Qt continues to 
 produce these types of problems, isn't there different library or 
 combination of libraries the developers can use?
 
 At the risk of sounding like a broken record: Some of the issues in the
 past have been caused by wrong usage within LyX (like repaint() instead
 of update()), and some by insisting to use Qt versions that have been
 released before the other components in the system, like newer versions
 of MacOSX. I just run svn up and README says The Qt4 library, at least
 version 4.2.2. For all features newer versions (e.g. Qt 4.6) are
 recommended. _Please_? That was state of the art in _2006_?
 
 That is not to say that Qt is flawless, Enrico(?)'s execvp/exeve
 issue for instance. But the thing _is_ open source, too, so if it's
 a pain point, fix it.

I second that. At the time of the move to Qt-exclusive it was debatable.
Now this isn't possible anymore. And Qt is an excellent toolkit.

 
 Back when I wrote my why oh why did you dump xforms rant, it seemed 
 like maybe the compile problems were just growing pains from Qt going 
 from version 3 to version 4. But now it's years later, and we're still 
 hearing (I paraphrase) the quality of your LyX program depends on 
 your Qt version.
 
 I know, you've told me before, Qt does a lot of busywork and makes 
 programming LyX much simpler. It handles all the localization, etc. 
 Programming LyX without Qt would be a horrendeous chore.
 
 But is Qt really doing you a favor when certain Qt versions make your 
 program perform badly?
 
 *gosh*
 
 The main performance problems I have seen so far are due to an abuse of
 the toolkit, not caused _by_ the toolkit (except for the remote raster
 painter problem perhaps). Just start at RowPainter::paintChars() and
 walk down through all the mess _before_ it actually hits Qt's drawText()
 It is slow? You bet.

Note, I've said: we have (aka LyX code has) a problem. 
This isn't easy to change - and we all do it in our spare time.
Everything around is a moving target - the OS and the Qt library.
And it isn't possible for every move to avoid drawbacks for the late comer.

For the painting problems: it started with broken ligature drawing and
the (re)action of LyX coders was a hack (split the text drawing at the letter 
'f'). 
As support for kerning for on-screen drawing was added (Qt 4.7 AFAIK) the 
consequence
was to split at every character. Obviously a rework of the painter/cursor 
movement
code is a much better action... but someone (who gets no money for this) has to 
do the job.
I had a look into this and decided I cannot afford that. I have a real live too.

All in all André is right: it's not the toolkit Qt, it's the use of it.

Stephan

Re: Qt: was Slow scrolling

[Stephan Witt]

Am 05.01.2012 um 05:16 schrieb Jerry:

 Do the developers monitor this list?

I think so.

 Or does someone need to file a bug report for the slow scrolling problem?

Perhaps. But ATM there is no problem description to reproduce it, AFAICS.
Some users have a problem only on Lion - you have it on Snow Leopard (SL) too.
I see no problem here on my system (SL) - perhaps I have lower requirements.

Stephan

Re: Qt: was Slow scrolling

[Jerry]

On Jan 4, 2012, at 11:36 PM, Stephan Witt wrote:

 Am 05.01.2012 um 05:16 schrieb Jerry:
 
 Do the developers monitor this list?
 
 I think so.
 
 Or does someone need to file a bug report for the slow scrolling problem?
 
 Perhaps. But ATM there is no problem description to reproduce it, AFAICS.
 Some users have a problem only on Lion - you have it on Snow Leopard (SL) too.
 I see no problem here on my system (SL) - perhaps I have lower requirements.
 
 Stephan

BTW, thanks for your help. I gather that you're the person who builds the Mac 
binaries.

Jerry

Re: Qt: was Slow scrolling

[André Pönitz]

On Wed, Jan 04, 2012 at 05:19:02PM -0500, Steve Litt wrote:
> On Tuesday, January 03, 2012 03:36:16 PM Stephan Witt wrote:
> > Am 03.01.2012 um 17:15 schrieb Olivier Ripoll:
> 
> > > Hi,
> > > 
> > > Check my 2 messages in the "LyX 2.0.2 Released" thread, one dated
> > > december 5th (user mailing lists, perhaps devel too) and the
> > > other one dated december 16th (devel ML), which contains more
> > > details:
> > > 
> > > http://www.mail-archive.com/lyx-users@lists.lyx.org/msg90218.html
> > > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg172462.htm
> > > l
> > 
> > Hi,
> > 
> > I'm almost sure it depends on Qt-Version.
> > 
> > With LyX on Mac with Qt4 we have two fundamental problems:
> 
> At the risk of sounding like a broken record, if Qt continues to 
> produce these types of problems, isn't there different library or 
> combination of libraries the developers can use?

At the risk of sounding like a broken record: Some of the issues in the
past have been caused by wrong usage within LyX (like repaint() instead
of update()), and some by insisting to use Qt versions that have been
released before the other components in the system, like newer versions
of MacOSX. I just run svn up and README says "The Qt4 library, at least
version 4.2.2. For all features newer versions (e.g. Qt 4.6) are
recommended." _Please_? That was state of the art in _2006_?

That is not to say that Qt is flawless, Enrico(?)'s execvp/exeve
issue for instance. But the thing _is_ open source, too, so if it's
a pain point, fix it.

> Back when I wrote my "why oh why did you dump xforms" rant, it seemed 
> like maybe the compile problems were just growing pains from Qt going 
> from version 3 to version 4. But now it's years later, and we're still 
> hearing (I paraphrase) "the quality of your LyX program depends on 
> your Qt version."
> 
> I know, you've told me before, Qt does a lot of busywork and makes 
> programming LyX much simpler. It handles all the localization, etc. 
> Programming LyX without Qt would be a horrendeous chore.
> 
> But is Qt really doing you a favor when certain Qt versions make your 
> program perform badly?

*gosh*

The main performance problems I have seesn so far are due to an abuse of
the toolkit, not caused _by_ the toolkit (except for the remote raster
painter problem perhaps). Just start at RowPainter::paintChars() and
walk down through all the mess _before_ it actually hits Qt's drawText()
It is slow? You bet.

> The LyX developers work so hard to create a 
> robust, high productivity program, only to have a tool vendor snatch 
> defeat from the jaws of victory. Isn't there another localization 
> library you can use, and another GUI library, and whatever?

Which one do you think would do the trick for Window, Mac _and_ Linux?
 
> Thanks

Please backport LyX to xforms. There was even a new release 1.0.93
in May 2010. If you have done it, and it loads the UserGuide I'll
shut up for eternity on that topic.

Andre'

Re: Qt: was Slow scrolling

[Stephan Witt]

Am 05.01.2012 um 02:40 schrieb André Pönitz:

> On Wed, Jan 04, 2012 at 05:19:02PM -0500, Steve Litt wrote:
>> On Tuesday, January 03, 2012 03:36:16 PM Stephan Witt wrote:
>>> Am 03.01.2012 um 17:15 schrieb Olivier Ripoll:
>> 
 Hi,
 
 Check my 2 messages in the "LyX 2.0.2 Released" thread, one dated
 december 5th (user mailing lists, perhaps devel too) and the
 other one dated december 16th (devel ML), which contains more
 details:
 
 http://www.mail-archive.com/lyx-users@lists.lyx.org/msg90218.html
 http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg172462.htm
 l
>>> 
>>> Hi,
>>> 
>>> I'm almost sure it depends on Qt-Version.
>>> 
>>> With LyX on Mac with Qt4 we have two fundamental problems:
>> 
>> At the risk of sounding like a broken record, if Qt continues to 
>> produce these types of problems, isn't there different library or 
>> combination of libraries the developers can use?
> 
> At the risk of sounding like a broken record: Some of the issues in the
> past have been caused by wrong usage within LyX (like repaint() instead
> of update()), and some by insisting to use Qt versions that have been
> released before the other components in the system, like newer versions
> of MacOSX. I just run svn up and README says "The Qt4 library, at least
> version 4.2.2. For all features newer versions (e.g. Qt 4.6) are
> recommended." _Please_? That was state of the art in _2006_?
> 
> That is not to say that Qt is flawless, Enrico(?)'s execvp/exeve
> issue for instance. But the thing _is_ open source, too, so if it's
> a pain point, fix it.

I second that. At the time of the move to Qt-exclusive it was debatable.
Now this isn't possible anymore. And Qt is an excellent toolkit.

> 
>> Back when I wrote my "why oh why did you dump xforms" rant, it seemed 
>> like maybe the compile problems were just growing pains from Qt going 
>> from version 3 to version 4. But now it's years later, and we're still 
>> hearing (I paraphrase) "the quality of your LyX program depends on 
>> your Qt version."
>> 
>> I know, you've told me before, Qt does a lot of busywork and makes 
>> programming LyX much simpler. It handles all the localization, etc. 
>> Programming LyX without Qt would be a horrendeous chore.
>> 
>> But is Qt really doing you a favor when certain Qt versions make your 
>> program perform badly?
> 
> *gosh*
> 
> The main performance problems I have seen so far are due to an abuse of
> the toolkit, not caused _by_ the toolkit (except for the remote raster
> painter problem perhaps). Just start at RowPainter::paintChars() and
> walk down through all the mess _before_ it actually hits Qt's drawText()
> It is slow? You bet.

Note, I've said: "we have (aka LyX code has) a problem". 
This isn't easy to change - and we all do it in our spare time.
Everything around is a moving target - the OS and the Qt library.
And it isn't possible for every move to avoid drawbacks for the late comer.

For the painting problems: it started with broken ligature drawing and
the (re)action of LyX coders was a hack (split the text drawing at the letter 
'f'). 
As support for kerning for on-screen drawing was added (Qt 4.7 AFAIK) the 
consequence
was to split at every character. Obviously a rework of the painter/cursor 
movement
code is a much better action... but someone (who gets no money for this) has to 
do the job.
I had a look into this and decided I cannot afford that. I have a real live too.

All in all André is right: it's not the toolkit Qt, it's the use of it.

Stephan

Re: Qt: was Slow scrolling

[Stephan Witt]

Am 05.01.2012 um 05:16 schrieb Jerry:

> Do the developers monitor this list?

I think so.

> Or does someone need to file a bug report for the slow scrolling problem?

Perhaps. But ATM there is no problem description to reproduce it, AFAICS.
Some users have a problem only on Lion - you have it on Snow Leopard (SL) too.
I see no problem here on my system (SL) - perhaps I have lower requirements.

Stephan

Re: Qt: was Slow scrolling

[Jerry]

On Jan 4, 2012, at 11:36 PM, Stephan Witt wrote:

> Am 05.01.2012 um 05:16 schrieb Jerry:
> 
>> Do the developers monitor this list?
> 
> I think so.
> 
>> Or does someone need to file a bug report for the slow scrolling problem?
> 
> Perhaps. But ATM there is no problem description to reproduce it, AFAICS.
> Some users have a problem only on Lion - you have it on Snow Leopard (SL) too.
> I see no problem here on my system (SL) - perhaps I have lower requirements.
> 
> Stephan

BTW, thanks for your help. I gather that you're the person who builds the Mac 
binaries.

Jerry