Enrico Forestieri wrote:
On Thu, Oct 25, 2007 at 03:55:50PM +0200, Enrico Forestieri wrote:
I really wonder why lyx 1.5.2 (official installer) is even faster than
1.6 on Windows, whereas the Cygwin version suffers the same problem as
on *nix. I'll try to build 1.5 using mingw and report back.
Pavel Sanda wrote:
Are you sure you disabled stdlib-debug?
yes, tuning ./configure helped. :)
Good :-)
btw next pagination miracle in 1.6: try to select text via shift+arrow inside
the box
and then press pg-up - the cursor moves, but the selection does not disappear.
I'll check this ou
On Thu, Oct 25, 2007 at 03:55:50PM +0200, Enrico Forestieri wrote:
> I really wonder why lyx 1.5.2 (official installer) is even faster than
> 1.6 on Windows, whereas the Cygwin version suffers the same problem as
> on *nix. I'll try to build 1.5 using mingw and report back.
A mingw build of 1.5.3
> Are you sure you disabled stdlib-debug?
yes, tuning ./configure helped. :)
btw next pagination miracle in 1.6: try to select text via shift+arrow inside
the box
and then press pg-up - the cursor moves, but the selection does not disappear.
p
>> not problem for 1.6 though.
>> 2) 1.6 - again open all insets. go with the cursor to the spaces between
>> first and second box. try pg-down and only view changes, cursor stand
>> where has previously been.
>
> Really? I cannot reproduce that... weird... Are you sure you aren't mixing
> up wi
On Thu, Oct 25, 2007 at 03:33:53PM +0200, Abdelrazak Younes wrote:
> Enrico Forestieri wrote:
> > On Thu, Oct 25, 2007 at 02:30:47PM +0200, Pavel Sanda wrote:
> >> No, I see absolutely no delay and the cpu remains low. But I see some
> >> drawing mistakes in the right box when I type: the
Pavel Sanda wrote:
1.5.2 - cpu usage 87%, but the speed is much better, you wont recognize it in
normal typing.
generally editing the box on this faster machine is ok, selectnig text
via arrow keys is slightly slower.
arrow/wheel motion on one page is ok, redraw to the next is ok.
> 1.5.2 - cpu usage 87%, but the speed is much better, you wont recognize it in
> normal typing.
> generally editing the box on this faster machine is ok, selectnig text
> via arrow keys is slightly slower.
>
> arrow/wheel motion on one page is ok, redraw to the next is ok.
have tri
Enrico Forestieri wrote:
On Thu, Oct 25, 2007 at 02:30:47PM +0200, Pavel Sanda wrote:
No, I see absolutely no delay and the cpu remains low. But I see some
drawing mistakes in the right box when I type: the corresponding line
disappears...
Now this is funny. I see the same problem as Pavel bot
On Thu, Oct 25, 2007 at 02:30:47PM +0200, Pavel Sanda wrote:
> > > > > No, I see absolutely no delay and the cpu remains low. But I see some
> > > > > drawing mistakes in the right box when I type: the corresponding line
> > > > > disappears...
> > > >
> > > > Now this is funny. I see the same p
Pavel Sanda wrote:
- when editing two Boxes placed side by side, which have already some more text
inside one gets quite amount of CPU work (no grahics, no maths involved) and
editing speed is slow. Selecting block of text has even worse latencies.
this behaviour seems to be dependent on h
> > - when editing two Boxes placed side by side, which have already some more
> > text
> > inside one gets quite amount of CPU work (no grahics, no maths involved)
> > and
> > editing speed is slow. Selecting block of text has even worse latencies.
> > this behaviour seems to be dependent
> > > > No, I see absolutely no delay and the cpu remains low. But I see some
> > > > drawing mistakes in the right box when I type: the corresponding line
> > > > disappears...
> > >
> > > Now this is funny. I see the same problem as Pavel both on Solaris
> > > and Windows when using a gcc buil
> please file bug reports for these to remind us. I'll be busy next week.
> - when deleting first few lines of text inside Box in the way that there
> remains empty line, the cursor movement outside of Box does not make that
> empty line vanish. the same at the end of Box. is this behaviour in
On Wed, Oct 24, 2007 at 11:58:30PM +0200, Pavel Sanda wrote:
> > > No, I see absolutely no delay and the cpu remains low. But I see some
> > > drawing mistakes in the right box when I type: the corresponding line
> > > disappears...
> >
> > Now this is funny. I see the same problem as Pavel both
> > No, I see absolutely no delay and the cpu remains low. But I see some
> > drawing mistakes in the right box when I type: the corresponding line
> > disappears...
>
> Now this is funny. I see the same problem as Pavel both on Solaris
> and Windows when using a gcc build. I don't see the probl
On Wed, Oct 24, 2007 at 10:01:43PM +0200, Abdelrazak Younes wrote:
> > sorry, no help. i attach one sample document. go into the first box
> > (somewhere
> > to the middle of it) and try fast typing. my cpu meter go to the 100% and
> > there is clear latency. do you see it too ?
>
> No, I see a
Pavel Sanda wrote:
- the fact that lyx cant correctly scroll either by mouse wheel or by
scrollbar
is really annoying. seems that the whole issue is caused by the fact,
that
after opening inset e.g. Box, its opened vertical size is not
considered.
when the inset gets vertically longer its
>> - the fact that lyx cant correctly scroll either by mouse wheel or by
>> scrollbar
>> is really annoying. seems that the whole issue is caused by the fact,
>> that
>> after opening inset e.g. Box, its opened vertical size is not
>> considered.
>> when the inset gets vertically longer it
Pavel Sanda wrote:
hi,
i had to start some real work under 1.5.2 and after hour or so of work
emerged this list of oddities:
- when deleting first few lines of text inside Box in the way that there
remains empty line, the cursor movement outside of Box does not make that
empty line vanish.
Pavel Sanda wrote:
> i had to start some real work under 1.5.2 and after hour or so of work
> emerged this list of oddities:
please file bug reports for these to remind us. I'll be busy next week.
Jürgen
hi,
i had to start some real work under 1.5.2 and after hour or so of work
emerged this list of oddities:
- when deleting first few lines of text inside Box in the way that there
remains empty line, the cursor movement outside of Box does not make that
empty line vanish. the same at the end o
22 matches
Mail list logo
