Jean-Marc Lasgouttes wrote:
"Darren" == Darren Freeman <[EMAIL PROTECTED]> writes:
Darren> I'm not asking for confirmation of the part I just introduced,
Darren> I only just said it.
Darren> But I know what I saw and I've since reproduced it again at my
Darren> end. Whatever is causing the slow
Bug added, see http://bugzilla.lyx.org/show_bug.cgi?id=3700
Have fun,
Darren
On Tue, 2007-05-22 at 15:34 +0200, Jean-Marc Lasgouttes wrote:
> > "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes:
>
> Darren> Please give me a little credit - there's been confirmations
> Darren> already.
> >> Confirmation of the complex behavior you describe? I did not see
> >> that.
On Tuesday 22 May 2007 4:08:22 pm Jean-Marc Lasgouttes wrote:
> He is on Suse. Could it be a bad clipboard interaction?
klipper has been working without problems for quite some time, but it can be
a suggestion to disable it and to see if the problem remains...
Using Fedora and kde I don't ha
> "Dov" == Dov Feldstern <[EMAIL PROTECTED]> writes:
>> That was something I tried early on - turning it off had no
>> effect.
Dov> Good. I mean, I'm glad that the bidi algorithm is not the
Dov> culprit. ;)
OTOH, at least we would have known where to search :)
JMarc
Darren Freeman wrote:
Next time, I'll make "top" always on top :)
You can also try xload, it's somewhat less intrusive.
Okay I have more to add.
In one instance I was able to get it to toggle from fast to slow by
selecting Document->TOC. It didn't speed up again with the TOC closed.
I checked the output of "top" and found my system to be 100.0% idle. (!)
And then I got it to go from slow to fast by resizing the L
Darren Freeman wrote:
On Tue, 2007-05-22 at 16:36 +0300, Dov Feldstern wrote:
I myself do not see this slowness. However, I suggest that people who
experience this try turning off the RTL option (Tools -> Preferences ->
Language settings -> Language -> Right-to-left language support). I seem
t
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Darren Freeman wrote:
>> On Tue, 2007-05-22 at 15:23 +0200, Pavel Sanda wrote:
But I know what I saw and I've since reproduced it again at my
end. Whatever is causing the slowdown I'm talking about, it
c
Darren Freeman wrote:
On Tue, 2007-05-22 at 15:23 +0200, Pavel Sanda wrote:
But I know what I saw and I've since reproduced it again at my end.
Whatever is causing the slowdown I'm talking about, it closes with LyX
is it possible to show the file you are talking about ?
I don't really want to
> I don't really want to publish a partly done thesis but I don't think it
> has anything to do with the particular document. I think you just have
i'm working with ~80 pages doc for a few days on slower hardware than you
indicated
and havent observed anything like that.
until there is some way
On Tue, 2007-05-22 at 16:36 +0300, Dov Feldstern wrote:
> I myself do not see this slowness. However, I suggest that people who
> experience this try turning off the RTL option (Tools -> Preferences ->
> Language settings -> Language -> Right-to-left language support). I seem
> to remember a com
On Tue, 2007-05-22 at 15:23 +0200, Pavel Sanda wrote:
> > But I know what I saw and I've since reproduced it again at my end.
> > Whatever is causing the slowdown I'm talking about, it closes with LyX
>
> is it possible to show the file you are talking about ?
I don't really want to publish a par
Hi!
I myself do not see this slowness. However, I suggest that people who
experience this try turning off the RTL option (Tools -> Preferences ->
Language settings -> Language -> Right-to-left language support). I seem
to remember a comment somewhere saying that 70% of the time is spent in
th
> "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes:
Darren> Please give me a little credit - there's been confirmations
Darren> already.
>> Confirmation of the complex behavior you describe? I did not see
>> that. Nobody disputes that there is a general slowness problem.
Darren> I'm not
Darren Freeman wrote:
On Tue, 2007-05-22 at 14:24 +0200, Abdelrazak Younes wrote:
Darren Freeman wrote:
I restarted LyX and created a new document - problem is gone. Even after
opening my thesis, problem isn't apparent. It looks like you may have to
do actual editing of an actual thesis to repr
Stefan Schimanski wrote:
Some profiling on Mac with Qt 4.2.x tells me:
* 18% QPainter::drawTextItem
* 18% QTextEngine::shape
* 70% paintPar (includes the upper two)
* 11% updateMetrics
So 70% of the whole painting process goes into paintPar. Am I wrong that
this part would go down more or less
> But I know what I saw and I've since reproduced it again at my end.
> Whatever is causing the slowdown I'm talking about, it closes with LyX
is it possible to show the file you are talking about ?
pavel
On Tue, 2007-05-22 at 14:48 +0200, Jean-Marc Lasgouttes wrote:
> > "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes:
>
> >> Yep. I really don't understand what could be the cause of the
> >> problem you're describing. I'd say it's not LyX fault but perhaps
> >> some other program that is
Some profiling on Mac with Qt 4.2.x tells me:
* 18% QPainter::drawTextItem
* 18% QTextEngine::shape
* 70% paintPar (includes the upper two)
* 11% updateMetrics
So 70% of the whole painting process goes into paintPar. Am I wrong
that this part would go down more or less linearly in the number o
> "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes:
>> Yep. I really don't understand what could be the cause of the
>> problem you're describing. I'd say it's not LyX fault but perhaps
>> some other program that is slowing down your computer.
Darren> ROFL! Oh wait, you're serious. :(
D
On Tue, 2007-05-22 at 14:24 +0200, Abdelrazak Younes wrote:
> Darren Freeman wrote:
> > I restarted LyX and created a new document - problem is gone. Even after
> > opening my thesis, problem isn't apparent. It looks like you may have to
> > do actual editing of an actual thesis to reproduce this!
Stefan Schimanski wrote:
Looking through the painting code... Is there a good reason that we
don't do partial redraws while scrolling?
Theoretically no. In practice, the way we do painting is inherited from
the multi-frontend approach. There are certainly things that can be
optimized.
I mea
Darren Freeman wrote:
Further to my earlier email, I suspect that the slowness is due to
gradually accumulating cruft in internal data structures. Maybe not a
memory leak but conceptually similar, possibly fragmentation or lists
that accumulate stale junk.
I had my thesis open, and editing was s
Stefan Schimanski wrote:
Looking through the painting code... Is there a good reason that we
don't do partial redraws while scrolling? I mean a lot of the screen
might be repaintable by just bitblt'ing the old image a bit upwards or
downwards. For the usual cursor movement this is not that impo
> "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes:
>> Did you compile with --disable-stdlib-debug? This is on for
>> development versions and has a bit cost in performance.
Darren> Doing that now, wasn't aware of it. Perhaps there should be
Darren> something mentioned in INSTALL under
Further to my earlier email, I suspect that the slowness is due to
gradually accumulating cruft in internal data structures. Maybe not a
memory leak but conceptually similar, possibly fragmentation or lists
that accumulate stale junk.
I had my thesis open, and editing was so slw. I created
On Tue, 2007-05-22 at 10:13 +0200, Jean-Marc Lasgouttes wrote:
> > "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes:
>
> Darren> Hi all, I know this was/is_being discussed in some form or
> Darren> another but I want to weigh in.
>
> Darren> On my system, AthlonXP3000+ w/ 1GB RAM, OpenSU
Looking through the painting code... Is there a good reason that we
don't do partial redraws while scrolling? I mean a lot of the screen
might be repaintable by just bitblt'ing the old image a bit upwards
or downwards. For the usual cursor movement this is not that
important because it is s
> "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes:
Darren> Hi all, I know this was/is_being discussed in some form or
Darren> another but I want to weigh in.
Darren> On my system, AthlonXP3000+ w/ 1GB RAM, OpenSUSE 10.2, I find
Darren> the SVN to be rather slow. I've jumped from the 1.3
On Tue, 2007-05-22 at 08:14 +0200, Anders Ekberg wrote:
> > Darren Freeman
> > A couple hundred milliseconds per mouse wheel scroll click isn't okay,
> > dammit!
> Did you try to compile with QT4.3 (pre-version)?
>
> At least on a Mac it improves things with about 30% (as compared to
> 4.2.x).
Am 22.05.2007 um 08:14 schrieb Anders Ekberg:
Darren Freeman
Mon, 21 May 2007 20:05:26 -0700
Hi all,
I know this was/is_being discussed in some form or another but I
want to
weigh in.
On my system, AthlonXP3000+ w/ 1GB RAM, OpenSUSE 10.2, I find the
SVN to
be rather slow. I've jumped fr
Darren Freeman
Mon, 21 May 2007 20:05:26 -0700
Hi all,
I know this was/is_being discussed in some form or another but I
want to
weigh in.
On my system, AthlonXP3000+ w/ 1GB RAM, OpenSUSE 10.2, I find the
SVN to
be rather slow. I've jumped from the 1.3/XForms world into the 1.5/Qt4
and can
Hi all,
I know this was/is_being discussed in some form or another but I want to
weigh in.
On my system, AthlonXP3000+ w/ 1GB RAM, OpenSUSE 10.2, I find the SVN to
be rather slow. I've jumped from the 1.3/XForms world into the 1.5/Qt4
and can hardly believe the change in performance.
A couple hu
34 matches
Mail list logo
