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 th
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 n
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 be
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 b
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 certa
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 certa
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 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 pre
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 th
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 sh
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
> "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
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 keyboard
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 a
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 he
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
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 amon
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
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
[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 applicati
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
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 Us
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 la
> "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
> "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
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
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).
> R
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 fro
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
> "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
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 othe
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
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 bac
On Wed, May 11, 2005 at 07:35:03PM +0100, John Levon wrote:
> 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 >= 0x
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 q
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.
Wha
> "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
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).
http://doc.trolltech.com/
> "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. Neverthl
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
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, 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 si
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
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
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 n
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
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
> "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 d
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 under
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
>
On Wed, 2005-05-11 at 17:33, Lars Gullik BjÃnnes 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..
> "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/ processEven
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 ke
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?
Regards,
Asger
On Wed, 2005-05-11 at 17:02, Lars Gullik BjÃnnes 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. Similar
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, n
> "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 fea
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
look
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
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, wi
> "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> previ
> "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.
> "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.
> "Andreas" == Andreas Vox <[EMAIL PROTECTED]> writes:
Andreas> Hi! I just remembered that this all started with enabling
Andreas> font caching or not...
Andreas> Here's what Qt/Aqua does in drawText(). If it does any
Andreas> caching it doesn't help much...
No, what we do in LyX is font wid
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 showCursor? This is very weird...
Not really.
sync_events(
> "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 showCursor? This is very weird...
JMarc
> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> (Note that the version of Shark I'm using is slightly updated
Bennett> from the version described on the webpage, so screenshots
Bennett> there don't exactly match what I see.)
I found another article about shark 4:
http://devel
On Apr 6, 2005, at 11:21 AM, Jean-Marc Lasgouttes wrote:
Good. Did you compile LyX with debug information? I cannot see any
reference to any LyX function...
Oops. I guess that would help. (Second attempt below, this time
confined to LyX and with all samples >=0.1.)
Do you know why there are 2 co
> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> I quit all applications other than Shark and LyX-140, and ran
Bennett> a time profile on all processes for 30 seconds (LyX
Bennett> represented 88.7% of the total). During that time, I typed
Bennett> into a long-ish document in L
On Wed, Apr 06, 2005 at 11:05:05AM -0400, Bennett Helm wrote:
> I quit all applications other than Shark and LyX-140, and ran a time
> profile on all processes for 30 seconds (LyX represented 88.7% of the
Can you do it just for LyX? The output doesn't seem to have anything
useful (and it's wa
70 matches
Mail list logo
