Andre Poenitz [EMAIL PROTECTED] writes:
| On Sat, May 14, 2005 at 04:02:10PM +0300, Martin Vermeer wrote:
On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
So why not solve that he other way round: Do not blink the
Andre Poenitz [EMAIL PROTECTED] writes:
| On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
So why not solve that he other way round: Do not blink the cursor unless
all draws have been finished?
I thought that's
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Sat, May 14, 2005 at 04:02:10PM +0300, Martin Vermeer wrote:
>> On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
>> > On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
>> >
>> > > So why not solve that he other way round: Do
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
>> On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
>>
>> > So why not solve that he other way round: Do not blink the cursor unless
>> > all draws have been finished?
>>
>> I
On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
So why not solve that he other way round: Do not blink the cursor unless
all draws have been finished?
I thought that's what Martin was planning (and it certainly sounds
right)
regards
john
On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
So why not solve that he other way round: Do not blink the cursor unless
all draws have been finished?
I thought that's what Martin was planning (and it certainly
On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
So why not solve that he other way round: Do not blink the cursor unless
all draws have been finished?
I thought that's what Martin was planning (and it certainly
On Sat, May 14, 2005 at 04:02:10PM +0300, Martin Vermeer wrote:
On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
So why not solve that he other way round: Do not blink the cursor unless
all draws have been
On Sat, May 14, 2005 at 08:42:08PM +0200, Andre Poenitz wrote:
On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
So why not solve that he other way round: Do not blink the cursor unless
all draws have been
On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
> So why not solve that he other way round: Do not blink the cursor unless
> all draws have been finished?
I thought that's what Martin was planning (and it certainly sounds
right)
regards
john
On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
> On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
>
> > So why not solve that he other way round: Do not blink the cursor unless
> > all draws have been finished?
>
> I thought that's what Martin was planning (and it
On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
> On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
>
> > So why not solve that he other way round: Do not blink the cursor unless
> > all draws have been finished?
>
> I thought that's what Martin was planning (and it
On Sat, May 14, 2005 at 04:02:10PM +0300, Martin Vermeer wrote:
> On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
> > On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
> >
> > > So why not solve that he other way round: Do not blink the cursor unless
> > > all draws have
On Sat, May 14, 2005 at 08:42:08PM +0200, Andre Poenitz wrote:
> On Sat, May 14, 2005 at 01:42:58PM +0100, John Levon wrote:
> > On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
> >
> > > So why not solve that he other way round: Do not blink the cursor unless
> > > all draws have
Martin Vermeer wrote:
On Wed, 2005-05-11 at 17:41, Asger Alstrup wrote:
Martin Vermeer wrote:
On Wed, 2005-05-11 at 17:02, Lars Gullik Bjønnes wrote:
How can events be reordered?
Precisely my question.
Did you check that your keyboard queue is really a queue, and not a stack?
There is no
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
Lars So it seems that my brilliant idea was a bit lousy. I do not see
Lars what | Qt machinery could help us, except perhaps
Lars QApplication::postEvent. We | could setup an eventFilter
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Lars | I am not even sure it would work, but it is similar to the
| Lars idea of | queueing key events for later use.
| Lars Then I think a queueing solution with coalescing of events is
| Lars nicer.
| Lars Then we just need a timer that kicks
On Thu, May 12, 2005 at 10:14:26AM +0200, Juergen Spitzmueller wrote:
I think we should try if LyX builds with Qt4 beta, then we have a real chance
that Qt4/Win Free will work too.
Qt4 is vastly different from Qt3. It's basically a new frontend from
LyX's point of view. It is impossible to
On Wed, May 11, 2005 at 04:16:53PM +0100, John Levon wrote:
Well, AFAICS that's only cosmetic. (Question: were there any
non-cosmetic problems with this? I don't see any.)
What a bizarre attitude! Cosmetics are how every single user interacts
with LyX, with the single exception of the LyX
On Thu, May 12, 2005 at 06:47:50PM +0200, Lars Gullik Bjønnes wrote:
this is kindo a proof-of-concept.
Is there a specific reason this queue is in the frontend and not in the
core?
If it were in the core we could have an 'update' lfuns, and a 'dont need
up-to-date cache' lfun flags and play
On Thu, May 12, 2005 at 04:05:27PM +0100, Angus Leeming wrote:
What is making it slower?
Is it the screen drawing or the new two-stage drawing thing?
In 1.3 we have a row cache and redraw only those rows that have changed.
In 1.4 we redraw the entire document on every single key press.
Martin Vermeer wrote:
On Wed, 2005-05-11 at 17:41, Asger Alstrup wrote:
Martin Vermeer wrote:
On Wed, 2005-05-11 at 17:02, Lars Gullik Bjønnes wrote:
How can events be reordered?
Precisely my question.
Did you check that your keyboard queue is really a queue, and not a stack?
There is no
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> So it seems that my brilliant idea was a bit lousy. I do not see
Lars> what | Qt machinery could help us, except perhaps
Lars> QApplication::postEvent. We | could setup
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Lars> | I am not even sure it would work, but it is similar to the
| Lars> idea of | queueing key events for later use.
>
| Lars> Then I think a queueing solution with coalescing of events is
| Lars> nicer.
>
| Lars> Then we just need a timer
On Thu, May 12, 2005 at 10:14:26AM +0200, Juergen Spitzmueller wrote:
> I think we should try if LyX builds with Qt4 beta, then we have a real chance
> that Qt4/Win Free will work too.
Qt4 is vastly different from Qt3. It's basically a new frontend from
LyX's point of view. It is impossible to
On Wed, May 11, 2005 at 04:16:53PM +0100, John Levon wrote:
> > Well, AFAICS that's only cosmetic. (Question: were there any
> > non-cosmetic problems with this? I don't see any.)
>
> What a bizarre attitude! Cosmetics are how every single user interacts
> with LyX, with the single exception of
On Thu, May 12, 2005 at 06:47:50PM +0200, Lars Gullik Bjønnes wrote:
> this is kindo a proof-of-concept.
Is there a specific reason this queue is in the frontend and not in the
core?
If it were in the core we could have an 'update' lfuns, and a 'dont need
up-to-date cache' lfun flags and play
On Thu, May 12, 2005 at 04:05:27PM +0100, Angus Leeming wrote:
> > What is making it slower?
> > Is it the screen drawing or the new two-stage drawing thing?
>
> In 1.3 we have a row cache and redraw only those rows that have changed.
> In 1.4 we redraw the entire document on every single key
John Levon wrote:
3.1.
OK, then we need to make that the minimum Qt version we support,
finally.
Agreed. As long as we silently take care that LyX at least builds against
Qt2/Win Free unless Qt4 is out.
Pity about Qt/Win Free or whatever it was but there's not much
we can do otherwise.
Bennett == Bennett Helm [EMAIL PROTECTED] writes:
Bennett But with a large-ish document (about 1 words and with
Bennett many footnotes, citations, and cross references, but with no
Bennett math or graphics), typing at a normal speed is simply
Bennett impossible: the order letters appear in
On Thu, 2005-05-12 at 15:57, Bennett Helm wrote:
On May 12, 2005, at 5:45 AM, Jean-Marc Lasgouttes wrote:
Bennett == Bennett Helm [EMAIL PROTECTED] writes:
Bennett But with a large-ish document (about 1 words and with
Bennett many footnotes, citations, and cross references, but with
On Thu, 2005-05-12 at 16:34, Andreas Vox wrote:
Am 11.05.2005 um 12:55 schrieb Jean-Marc Lasgouttes:
...
It would be interesting to know how things have evolved since Martin's
latest patch.
showCursor() is still recursive.
Yes, but it is allowed to be. It is called also from outside
Martin Vermeer wrote:
1. Instead of reordering keystrokes, it drops keystrokes. Thus, typing
The last time I tested lyx results in: Th attm Itsedlx.
I don't manage to reproduce this, even in the User Guide. But I'm not a
fast typist.
I see it when using LyX remotely (Qt/X11).
Remember,
Angus Leeming [EMAIL PROTECTED] writes:
| Martin Vermeer wrote:
1. Instead of reordering keystrokes, it drops keystrokes. Thus, typing
The last time I tested lyx results in: Th attm Itsedlx.
I don't manage to reproduce this, even in the User Guide. But I'm not a
fast typist.
| I see it
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin QFontEngineMac::doTextTask eating 55% of your CPU? Or spending
Martin 55% of its time there, waiting for drawing to finish?
That's weird, especially since none of this time is credited to a
lower-level function.
Martin Older LyX also
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Angus Leeming [EMAIL PROTECTED] writes:
Lars | Martin Vermeer wrote:
1. Instead of reordering keystrokes, it drops keystrokes. Thus,
typing The last time I tested lyx results in: Th attm
Itsedlx.
I don't manage to reproduce this,
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| So it seems that my brilliant idea was a bit lousy. I do not see what
| Qt machinery could help us, except perhaps QApplication::postEvent. We
| could setup an eventFilter for the application that fileters user
| input events and posts them for
Lars Gullik Bjønnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| Martin Vermeer wrote:
1. Instead of reordering keystrokes, it drops keystrokes. Thus, typing
The last time I tested lyx results in: Th attm Itsedlx.
I don't manage to reproduce this, even in the User Guide. But I'm not
On Thu, 2005-05-12 at 17:53, Jean-Marc Lasgouttes wrote:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
...
So it seems that my brilliant idea was a bit lousy. I do not see what
Qt machinery could help us, except perhaps QApplication::postEvent. We
could setup an eventFilter for the
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| | So it seems that my brilliant idea was a bit lousy. I do not see what
| | Qt machinery could help us, except perhaps QApplication::postEvent. We
| | could setup an eventFilter for the application
Juergen Spitzmueller wrote:
Agreed. As long as we silently take care that LyX at least builds against
Qt2/Win Free unless Qt4 is out.
I will care about Qt 3/Win Free (which BTW is version 3.3.4)
Michael
On Thu, 2005-05-12 at 18:05, Angus Leeming wrote:
...
What is making it slower?
Is it the screen drawing or the new two-stage drawing thing?
In 1.3 we have a row cache and redraw only those rows that have changed.
In 1.4 we redraw the entire document on every single key press. If the
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| | Then we just need a timer that kicks in some 10-20 times a second to
| | check the queue and do the real work.
| and with the queue doing the right thing we can actually put
| processEvents allover as much as we want to to make the interactive
Martin Vermeer [EMAIL PROTECTED] writes:
So... where is events ditched?
| Well, if you call processEvents with QEventLoop::ExcludeUserInput, what
| happens is (I think) that whenever the call empties the X event queue,
| those events that are user input (i.e., keystrokes among others) are
On Thu, May 12, 2005 at 06:47:50PM +0200, Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| | Then we just need a timer that kicks in some 10-20 times a second to
| | check the queue and do the real work.
| and with the queue doing the right thing we can actually
Angus Leeming wrote:
In 1.3 we have a row cache and redraw only those rows that have changed.
In 1.4 we redraw the entire document on every single key press. If the row
is 'on screen' then the real painter is called. If not, then the painting
is performed by the null painter.
I think you are
On Thu, May 12, 2005 at 06:19:39PM +0300, Martin Vermeer wrote:
On Thu, 2005-05-12 at 17:53, Jean-Marc Lasgouttes wrote:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
...
So it seems that my brilliant idea was a bit lousy. I do not see what
Qt machinery could help us, except
Helge Hafting [EMAIL PROTECTED] writes:
| Loosing keypresses that actually got delivered to lyx won't do.
| Even a horribly lagging lyx is better than that.
| (Loosing autorepeats _by design_ is of course ok.)
This is what my patch tries to do... never loose keyevents but prune
autorepeats to
John Levon wrote:
> > 3.1.
>
> OK, then we need to make that the minimum Qt version we support,
> finally.
Agreed. As long as we silently take care that LyX at least builds against
Qt2/Win Free unless Qt4 is out.
> Pity about Qt/Win Free or whatever it was but there's not much
> we can do
> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> But with a large-ish document (about 1 words and with
Bennett> many footnotes, citations, and cross references, but with no
Bennett> math or graphics), typing at a normal speed is simply
Bennett> impossible: the order
On Thu, 2005-05-12 at 15:57, Bennett Helm wrote:
> On May 12, 2005, at 5:45 AM, Jean-Marc Lasgouttes wrote:
>
> >> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
> >
> > Bennett> But with a large-ish document (about 1 words and with
> > Bennett> many footnotes, citations, and cross
On Thu, 2005-05-12 at 16:34, Andreas Vox wrote:
> Am 11.05.2005 um 12:55 schrieb Jean-Marc Lasgouttes:
...
> >
> > It would be interesting to know how things have evolved since Martin's
> > latest patch.
>
>
> showCursor() is still recursive.
Yes, but it is allowed to be. It is called also
Martin Vermeer wrote:
>> 1. Instead of reordering keystrokes, it drops keystrokes. Thus, typing
>> "The last time I tested lyx" results in: "Th attm Itsedlx".
>
> I don't manage to reproduce this, even in the User Guide. But I'm not a
> fast typist.
I see it when using LyX remotely (Qt/X11).
>
Angus Leeming <[EMAIL PROTECTED]> writes:
| Martin Vermeer wrote:
>>> 1. Instead of reordering keystrokes, it drops keystrokes. Thus, typing
>>> "The last time I tested lyx" results in: "Th attm Itsedlx".
>>
>> I don't manage to reproduce this, even in the User Guide. But I'm not a
>> fast
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> QFontEngineMac::doTextTask eating 55% of your CPU? Or spending
Martin> 55% of its time there, waiting for drawing to finish?
That's weird, especially since none of this time is credited to a
lower-level function.
Martin> Older
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Angus Leeming <[EMAIL PROTECTED]> writes:
Lars> | Martin Vermeer wrote:
1. Instead of reordering keystrokes, it drops keystrokes. Thus,
typing "The last time I tested lyx" results in: "Th attm
Itsedlx".
>>> I
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| So it seems that my brilliant idea was a bit lousy. I do not see what
| Qt machinery could help us, except perhaps QApplication::postEvent. We
| could setup an eventFilter for the application that fileters user
| input events and posts them for
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Martin Vermeer wrote:
1. Instead of reordering keystrokes, it drops keystrokes. Thus, typing
"The last time I tested lyx" results in: "Th attm Itsedlx".
>>>
>>> I don't manage to reproduce this, even in the
On Thu, 2005-05-12 at 17:53, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> So it seems that my brilliant idea was a bit lousy. I do not see what
> Qt machinery could help us, except perhaps QApplication::postEvent. We
> could setup an
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
| | So it seems that my brilliant idea was a bit lousy. I do not see what
| | Qt machinery could help us, except perhaps QApplication::postEvent. We
| | could setup an eventFilter for the
Juergen Spitzmueller wrote:
Agreed. As long as we silently take care that LyX at least builds against
Qt2/Win Free unless Qt4 is out.
I will care about Qt 3/Win Free (which BTW is version 3.3.4)
Michael
On Thu, 2005-05-12 at 18:05, Angus Leeming wrote:
...
> > What is making it slower?
> > Is it the screen drawing or the new two-stage drawing thing?
>
> In 1.3 we have a row cache and redraw only those rows that have changed.
> In 1.4 we redraw the entire document on every single key press.
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| | Then we just need a timer that kicks in some 10-20 times a second to
| | check the queue and do the real work.
>
| and with the queue doing the right thing we can actually put
| processEvents allover as much as we want to to make the interactive
Martin Vermeer <[EMAIL PROTECTED]> writes:
>> >> So... where is events ditched?
>> >
>> | Well, if you call processEvents with QEventLoop::ExcludeUserInput, what
>> | happens is (I think) that whenever the call empties the X event queue,
>> | those events that are user input (i.e., keystrokes
On Thu, May 12, 2005 at 06:47:50PM +0200, Lars Gullik Bjønnes wrote:
> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
>
> | | Then we just need a timer that kicks in some 10-20 times a second to
> | | check the queue and do the real work.
> >
> | and with the queue doing the right thing we can
Angus Leeming wrote:
> In 1.3 we have a row cache and redraw only those rows that have changed.
> In 1.4 we redraw the entire document on every single key press. If the row
> is 'on screen' then the real painter is called. If not, then the painting
> is performed by the null painter.
I think you
On Thu, May 12, 2005 at 06:19:39PM +0300, Martin Vermeer wrote:
> On Thu, 2005-05-12 at 17:53, Jean-Marc Lasgouttes wrote:
> > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> ...
>
> > So it seems that my brilliant idea was a bit lousy. I do not see what
> > Qt machinery could
Helge Hafting <[EMAIL PROTECTED]> writes:
| Loosing keypresses that actually got delivered to lyx won't do.
| Even a horribly lagging lyx is better than that.
| (Loosing autorepeats _by design_ is of course ok.)
This is what my patch tries to do... never loose keyevents but prune
autorepeats to
Andreas == Andreas Vox [EMAIL PROTECTED] writes:
Andreas Am 07.04.2005 um 17:58 schrieb Jean-Marc Lasgouttes:
Andreas == Andreas Vox [EMAIL PROTECTED] writes:
Andreas I also did some profiling and got the attached screenshot
Andreas when scrolling down using PageDown.
Do I really see 38% in
Bennett == Bennett Helm [EMAIL PROTECTED] writes:
Bennett On May 11, 2005, at 6:55 AM, Jean-Marc Lasgouttes wrote:
It would be interesting to know how things have evolved since
Martin's latest patch.
Bennett Here you go -- profile attached, done the same way as my
Bennett previous report:
On Wed, 2005-05-11 at 16:36, Bennett Helm wrote:
On May 11, 2005, at 6:55 AM, Jean-Marc Lasgouttes wrote:
It would be interesting to know how things have evolved since Martin's
latest patch.
Here you go -- profile attached, done the same way as my previous
report: tree view, with
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Bennett Thus, if I type 1234 quickly (but slowly enough to be sure
| Bennett I'm typing them in that order!), I actually get 1342 or
| Bennett 1432 in the document. Similarly, typing The last time I
| Bennett tested lyx results in The lsttim Iteted
On Wed, May 11, 2005 at 04:58:47PM +0300, Martin Vermeer wrote:
Does anyone have an idea how the input order reversal could come about?
Again, are there any guarantees that the X queue gives events back in
time order?
I believe there is not, but Qt should be dealing with that for us by
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin Does anyone have an idea how the input order reversal could
Martin come about? Again, are there any guarantees that the X queue
Martin gives events back in time order?
I do not know many X apps that share this entertaining feature with
Martin Vermeer [EMAIL PROTECTED] writes:
| Oops, that's bad. Could this be due to calling sync_events twice during
| a cursor blink sequence? (both in showCursor and in hideCursor.) I did
| that to make LyX snappier ;-/
Hmm... this shouldn't be needed to make LyX snappier...
| Alternatively,
On Wed, 2005-05-11 at 17:02, Lars Gullik Bjnnes wrote:
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Bennett Thus, if I type 1234 quickly (but slowly enough to be sure
| Bennett I'm typing them in that order!), I actually get 1342 or
| Bennett 1432 in the document. Similarly, typing The
Martin Vermeer wrote:
On Wed, 2005-05-11 at 17:02, Lars Gullik Bjnnes wrote:
How can events be reordered?
Precisely my question.
Did you check that your keyboard queue is really a queue, and not a stack?
Regards,
Asger
On Wed, 2005-05-11 at 17:41, Asger Alstrup wrote:
Martin Vermeer wrote:
On Wed, 2005-05-11 at 17:02, Lars Gullik Bjnnes wrote:
How can events be reordered?
Precisely my question.
Did you check that your keyboard queue is really a queue, and not a stack?
There is no keyboard (or
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin Does anyone have an idea how the input order reversal could
Martin come about? Again, are there any guarantees that the X queue
Martin gives events back in time order?
Maybe something like:
1/ an event arrives
2/ processEvents is
On Wed, 2005-05-11 at 17:33, Lars Gullik Bjnnes wrote:
Martin Vermeer [EMAIL PROTECTED] writes:
| Oops, that's bad. Could this be due to calling sync_events twice during
| a cursor blink sequence? (both in showCursor and in hideCursor.) I did
| that to make LyX snappier ;-/
Hmm... this
On Wed, May 11, 2005 at 06:12:53PM +0300, Martin Vermeer wrote:
What came back was the original problem why sync_events was introduced:
when scrolling fast in big documents (PageDown) the screen update
doesn't keep up.
- // You are not expected to understand this. This forces Qt
-
John Levon wrote:
On Wed, May 11, 2005 at 06:12:53PM +0300, Martin Vermeer wrote:
What came back was the original problem why sync_events was introduced:
when scrolling fast in big documents (PageDown) the screen update
doesn't keep up.
- // You are not expected to understand this.
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus H. Rather than process all pending draw events fully, is it
Angus sufficient to process the last draw event and discard the
Angus earlier ones? Ie, we should be computing the metrics() on each
Angus page-down, but we should draw() only
On Wed, 2005-05-11 at 18:05, Jean-Marc Lasgouttes wrote:
...
What about using something like
qApp-eventLoop()-processEvents(QEventLoop::ExcludeUserInput);
It looks to me as the right answer (do the drawing, not the use input)
JMarc
Jean-Marc, you're a gem!
It works precisely as it
On Wed, May 11, 2005 at 05:05:47PM +0200, Jean-Marc Lasgouttes wrote:
qApp-eventLoop()-processEvents(QEventLoop::ExcludeUserInput);
When was this flag introduced to Qt?
john
John Levon [EMAIL PROTECTED] writes:
| On Wed, May 11, 2005 at 06:12:53PM +0300, Martin Vermeer wrote:
What came back was the original problem why sync_events was introduced:
when scrolling fast in big documents (PageDown) the screen update
doesn't keep up.
- // You are not expected
On Wed, May 11, 2005 at 04:28:02PM +0100, Angus Leeming wrote:
H. Rather than process all pending draw events fully, is it sufficient
to process the last draw event and discard the earlier ones? Ie, we should
be computing the metrics() on each page-down, but we should draw() only if
On Wed, May 11, 2005 at 04:57:11PM +0100, John Levon wrote:
On Wed, May 11, 2005 at 05:05:47PM +0200, Jean-Marc Lasgouttes wrote:
qApp-eventLoop()-processEvents(QEventLoop::ExcludeUserInput);
When was this flag introduced to Qt?
Has to be said that I don't see any of the problems about
On Wed, 2005-05-11 at 18:57, John Levon wrote:
On Wed, May 11, 2005 at 05:05:47PM +0200, Jean-Marc Lasgouttes wrote:
qApp-eventLoop()-processEvents(QEventLoop::ExcludeUserInput);
When was this flag introduced to Qt?
3.1.
- Martin
signature.asc
Description: This is a digitally signed
On Wed, May 11, 2005 at 05:07:28PM +0100, John Levon wrote:
Has to be said that I don't see any of the problems about drawing
with current CVS...
But I do see the keypress re-ordering.
john
On Wed, May 11, 2005 at 07:07:26PM +0300, Martin Vermeer wrote:
When was this flag introduced to Qt?
3.1.
OK, then we need to make that the minimum Qt version we support,
finally. Pity about Qt/Win Free or whatever it was but there's not much
we can do otherwise.
regards
john
John == John Levon [EMAIL PROTECTED] writes:
John On Wed, May 11, 2005 at 05:05:47PM +0200, Jean-Marc Lasgouttes
John wrote:
qApp- eventLoop()-processEvents(QEventLoop::ExcludeUserInput);
John When was this flag introduced to Qt?
Good question. It seems that it is Qt 3.1. Neverthless, I think
John Levon wrote:
On Wed, May 11, 2005 at 05:05:47PM +0200, Jean-Marc Lasgouttes wrote:
qApp-eventLoop()-processEvents(QEventLoop::ExcludeUserInput);
When was this flag introduced to Qt?
john
There's a QEventLoop in Qt 3.1 (released November 13 2002).
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin Patch attached. Please commit, this is your baby.
Feel free to do it, I am busy now. I guess you should guard it with
#if QTVERSION = 0x030100
so that older qt will only suffer from drawing glitches.
JMarc
On Wed, May 11, 2005 at 07:44:30PM +0200, Jean-Marc Lasgouttes wrote:
Martin Patch attached. Please commit, this is your baby.
Feel free to do it, I am busy now. I guess you should guard it with
#if QTVERSION = 0x030100
so that older qt will only suffer from drawing glitches.
What about
John Levon [EMAIL PROTECTED] writes:
| On Wed, May 11, 2005 at 07:44:30PM +0200, Jean-Marc Lasgouttes wrote:
Martin Patch attached. Please commit, this is your baby.
Feel free to do it, I am busy now. I guess you should guard it with
#if QTVERSION = 0x030100
so that older qt will only
On Wed, May 11, 2005 at 10:34:37PM +0300, Martin Vermeer wrote:
I think Jean-Marc wants to eliminate processEvents altogether for older
Qt. Then we will only suffer the drawing glitches that you objected so
vehemently against. I think a reasonable Faustian deal against forcing
people back to
On Wed, May 11, 2005 at 07:44:30PM +0200, Jean-Marc Lasgouttes wrote:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin Patch attached. Please commit, this is your baby.
Feel free to do it, I am busy now. I guess you should guard it with
#if QTVERSION = 0x030100
so that older
> "Andreas" == Andreas Vox <[EMAIL PROTECTED]> writes:
Andreas> Am 07.04.2005 um 17:58 schrieb Jean-Marc Lasgouttes:
>>> "Andreas" == Andreas Vox <[EMAIL PROTECTED]> writes:
>>
Andreas> I also did some profiling and got the attached screenshot
Andreas> when scrolling down using PageDown.
> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> On May 11, 2005, at 6:55 AM, Jean-Marc Lasgouttes wrote:
>> It would be interesting to know how things have evolved since
>> Martin's latest patch.
Bennett> Here you go -- profile attached, done the same way as my
Bennett>
1 - 100 of 146 matches
Mail list logo
