Tommaso Cucinotta wrote:
Abdelrazak Younes ha scritto:
GuiApplication). On a related note we have
WorkArea::scheduleRedraw() that was created for the purpose of
delayed screen updates (scheduled to happen at next cursor blink).
I know. Actually, I cannot imagine a use-case in which delaying
scr
Abdelrazak Younes ha scritto:
GuiApplication). On a related note we have WorkArea::scheduleRedraw()
that was created for the purpose of delayed screen updates (scheduled
to happen at next cursor blink).
I know. Actually, I cannot imagine a use-case in which delaying screen
redraw to next cursor
Tommaso Cucinotta wrote:
Helge Hafting ha scritto:
He offered to do the calculation in the background. That gives the
I'm already on the way ... almost working, but need further debugging.
After that, guess my last change will be to make Abdel happy and
confine the nice-scrolling behaviour with
Andre Poenitz ha scritto:
I mean, something like GuiView::doWhenIdle(this, &myMethod):
template static GuiView::doWhenIdle(T *, bool (T::*)(void))
[I am not sure about the utility of this approach. No need to
proactively introduce funny template constructs ;-}]
The utility comes if the
On Mon, Nov 12, 2007 at 08:11:38PM +0100, Tommaso Cucinotta wrote:
> Helge Hafting ha scritto:
>> He offered to do the calculation in the background. That gives the
> I'm already on the way ... almost working, but need further debugging.
> After that, guess my last change will be to make Abdel happ
Helge Hafting ha scritto:
He offered to do the calculation in the background. That gives the
I'm already on the way ... almost working, but need further debugging.
After that, guess my last change will be to make Abdel happy and
confine the nice-scrolling behaviour within the BufferView class, s
Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Sun, Nov 11, 2007 at 04:39:22PM +0100, Tommaso Cucinotta wrote:
If you have serious concerns about this (probably due to the
past experience on developing LyX), the best solution would
be a "summing (balanced) tree", that would exhibit O(log n)
Tommaso Cucinotta wrote:
Abdelrazak Younes ha scritto:
I don't like this distinction. I prefer all or nothing.
Well, if you really think it is preferreable, then it would
probably be a matter of a few minutes to create a new vector
TextMetrics::par_heights_[], in addition to the par_metrics_[]
Abdelrazak Younes ha scritto:
I don't like this distinction. I prefer all or nothing.
Well, if you really think it is preferreable, then it would
probably be a matter of a few minutes to create a new vector
TextMetrics::par_heights_[], in addition to the par_metrics_[]
one, and let the parHeight
Tommaso Cucinotta wrote:
Abdelrazak Younes ha scritto:
We don't need a *perfect* scrolling behaviour, just a sensible one.
I agree we may accept a non-perfect scrolling right after having opened
a document, or having made great changes. But, IMHO, after a while
it would be better to have a prec
Andre Poenitz ha scritto:
Just copy the UserGuide 20 times into itself.
Done. I get a time roughly doubled:
trunk: 5.5 secs
scrollfix: 10.5 secs
Well, I guess nobody really works with so large documents,
but you have at least one file per chapter. Though, I can
add the background-incrementa
Abdelrazak Younes ha scritto:
We don't need a *perfect* scrolling behaviour, just a sensible one.
I agree we may accept a non-perfect scrolling right after having opened
a document, or having made great changes. But, IMHO, after a while
it would be better to have a precise behaviour, while readi
On Sun, Nov 11, 2007 at 08:59:01PM +0100, Tommaso Cucinotta wrote:
> Conclusions: the unscientific experiment of Andre Poenits was really
> non-scientific. I guess he must have left debug enabled when trying
> the scrollfix, and disabled in the other case :-) Another possibility
> could be he trie
0m0.112s
This is my scrollfix patch, as sent to the list tonight:
[EMAIL PROTECTED]:~/lyx-devel$ time sudo nice ./src/lyx
lib/doc/UserGuide.lyx > /dev/null 2>&1
real0m2.611s
user0m1.719s
sys 0m0.110s
And now again trunk for EMBEDDEDOBJECTS.LYX:
[EMAIL PROTECTED]:~/lyx-trunk
Andre Poenitz wrote:
On Sun, Nov 11, 2007 at 06:46:38PM +0100, Alfredo Braunstein wrote:
A small point: when testing we should not limit ourselves to the Userguide.
IMO one of the really strong points of LyX is to be able to deal with huge
documents, like books. (the UG has just 150 pages, it is
On Sun, Nov 11, 2007 at 08:08:52PM +0100, Andre Poenitz wrote:
> On Sun, Nov 11, 2007 at 05:25:20PM +0100, Tommaso Cucinotta wrote:
> > Andre Poenitz ha scritto:
> >> An entirely unscientific test (sitting in front of the computer and
> >> counting) yields ~4s for loading the UserGuide before apply
On Sun, Nov 11, 2007 at 06:46:38PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > On Sun, Nov 11, 2007 at 01:21:03PM +0100, Andre Poenitz wrote:
> >> > I think this is the time to check it in -- with the trivial
> >> > renames you propose. We're not close to a trunk release so any
>
On Sun, Nov 11, 2007 at 06:21:45PM +0100, Abdelrazak Younes wrote:
>> 20 is rather not.
>> I know, it's not that bad, I am exaggerating. And of course
>> one could provide some more versose status message (as in 23/5490
>> paragraphs done) giving the impression that 'something' happens...
>
> That'
On Sun, Nov 11, 2007 at 05:25:20PM +0100, Tommaso Cucinotta wrote:
> Andre Poenitz ha scritto:
>> An entirely unscientific test (sitting in front of the computer and
>> counting) yields ~4s for loading the UserGuide before applying the patch
>> and ~13s afterwards. There is some additional debug ou
Tommaso Cucinotta wrote:
> Andre Poenitz ha scritto:
>> ourselves into a corner here. We had this kind of approach (all
>> paragraph heights known) for a long time and switched to the
>> current one for performance reasons when e.g. loading/resizing
>> inserting in big docments.
>>
> My feeling
Andre Poenitz wrote:
> On Sun, Nov 11, 2007 at 01:21:03PM +0100, Andre Poenitz wrote:
>> > I think this is the time to check it in -- with the trivial
>> > renames you propose. We're not close to a trunk release so any
>> > bugs will get ironed out in a timely manner.
>>
>> I'd like to see some p
Abdelrazak Younes wrote:
>>> If you have serious concerns about this (probably due to the
>>> past experience on developing LyX), the best solution would
>>> be a "summing (balanced) tree", that would exhibit O(log n)
>>> complexity for little updates like needed in 1) [not sure about
>>> 1.a], bu
Andre Poenitz wrote:
>> 1) change of height of currently edited par
>> 1.a) break of currently edited par (Enter)
>> 2) cut and paste operations
>> 3) width resize of screen
>
> 4) Loading of a document.
>
>> If you have serious concerns about this (probably due to the
>> past experience on de
Andre Poenitz wrote:
On Sun, Nov 11, 2007 at 04:39:22PM +0100, Tommaso Cucinotta wrote:
If you have serious concerns about this (probably due to the
past experience on developing LyX), the best solution would
be a "summing (balanced) tree", that would exhibit O(log n)
complexity for little upd
On Sun, Nov 11, 2007 at 04:39:22PM +0100, Tommaso Cucinotta wrote:
> Andre Poenitz ha scritto:
>> ourselves into a corner here. We had this kind of approach (all
>> paragraph heights known) for a long time and switched to the current one
>> for performance reasons when e.g. loading/resizing
>> ins
Andre Poenitz ha scritto:
An entirely unscientific test (sitting in front of the computer and
counting) yields ~4s for loading the UserGuide before applying the patch
and ~13s afterwards. There is some additional debug output, but I don't
think the resulting scrolling in the terminal accounts for
Andre Poenitz ha scritto:
An entirely unscientific test (sitting in front of the computer and
counting) yields ~4s for loading the UserGuide before applying the patch
and ~13s afterwards. There is some additional debug output, but I don't
think the resulting scrolling in the terminal accounts for
Andre Poenitz ha scritto:
ourselves into a corner here. We had this kind of approach (all
paragraph heights known) for a long time and switched to the
current one for performance reasons when e.g. loading/resizing
inserting in big docments.
My feeling is that, even with hundreds of outer pa
On Sun, Nov 11, 2007 at 01:53:52PM +0100, Andre Poenitz wrote:
> On Sun, Nov 11, 2007 at 01:21:03PM +0100, Andre Poenitz wrote:
> > > I think this is the time to check it in -- with the trivial
> > > renames you propose. We're not close to a trunk release so any
> > > bugs will get ironed out in a
On Sun, Nov 11, 2007 at 01:21:03PM +0100, Andre Poenitz wrote:
> > I think this is the time to check it in -- with the trivial
> > renames you propose. We're not close to a trunk release so any
> > bugs will get ironed out in a timely manner.
>
> I'd like to see some performance measures first, le
On Sun, Nov 11, 2007 at 07:49:54AM +0200, Martin Vermeer wrote:
> On Sun, Nov 11, 2007 at 05:24:36AM +0100, Tommaso Cucinotta wrote:
> > Hi all,
> >
> > please, find attached an improved version of the scrollfix patch.
> >
> > Summary of the further change
Abdelrazak Younes wrote:
It this patch goes as-is you have to promise to fixed all bugs and
regressions Tommaso (I would help you of course).
If this patch goes in as-is you have to promise to fix all bugs and
regressions Tommaso (I would help you of course).
I'll to do a review of the p
Martin Vermeer wrote:
On Sun, Nov 11, 2007 at 05:24:36AM +0100, Tommaso Cucinotta wrote:
As it is somewhat growing, I wouldn't like to keep working on it for too
much time further, as the operation of merging with trunk may become
cumbersome. Now it seems to me sufficiently stable.
T.
> -) the boxes example now works correctly, except it is somewhat slow
> because with SinglePar I'm updating and redrawing the outer Par,
> not the inner one, so with such a great box (or even table, etc...),
> it gets slow -- here I should add a further parameter to UpdateScope
> specifyin
On Sun, Nov 11, 2007 at 05:24:36AM +0100, Tommaso Cucinotta wrote:
> Hi all,
>
> please, find attached an improved version of the scrollfix patch.
>
> Summary of the further changes:
> -) most optimizations for updating a single par are back
> -) actually, it is poss
On Thu, 08 Nov 2007 15:33:55 +0100
Tommaso Cucinotta <[EMAIL PROTECTED]> wrote:
...
> It seems in this practical world, nobody cares anymore about optimizations.
> After all, we have to give something to do to our quad-core machines,
> right ? :-)
>
> I know perfectly what you're talking about,
Helge Hafting ha scritto:
Ideally, you don't update the entire screen on scrolling.
If the scroll is less than a screenfull, just let the windowing
system move the part that stays visible. And then you draw
only the exposed part. A nice speedup, especially when working
across the network.
Ideall
Tommaso Cucinotta wrote:
Helge Hafting ha scritto:
6) I said that already but there's a number of optimisation that are
gone now because you basically do a full screen update at each
operation.
Please, note that the updateFlags are still correctly produced by the
various
(quite obscure) code
On Wed, Nov 07, 2007 at 12:04:46AM +0100, Tommaso Cucinotta wrote:
> Any comments by anyone is welcome.
It does not apply to trunk:
patching file src/ParagraphMetrics.h
patching file src/insets/InsetInclude.cpp
patching file src/insets/InsetText.cpp
patching file src/BufferView.cpp
Hunk #1 FAILED
> please find attached a first attempt of fixing the non-uniform scrolling
> of LyX on trunk (21411).
it seems this patch breaks view of boxes. try e.g.
http://bugzilla.lyx.org/attachment.cgi?id=2218&action=view
in 1.5 and in patched trunk to see the difference. paragraph
does not respect width o
Abdelrazak Younes ha scritto:
hope you won't let us down :-). The downside of your patch is that it
erases most of the optimisation I've worked hard to preserve.
Guess I can preserve such optimizations (i.e. the updateFlags
computation and management) -- see also my
previous msg. My aim is to r
Helge Hafting ha scritto:
6) I said that already but there's a number of optimisation that are
gone now because you basically do a full screen update at each
operation.
Please, note that the updateFlags are still correctly produced by the
various
(quite obscure) code segments around. Except th
Abdelrazak Younes wrote:
Tommaso Cucinotta wrote:
Hi Abdel,
please find attached a first attempt of fixing the non-uniform scrolling
of LyX on trunk (21411).
6) I said that already but there's a number of optimisation that are
gone now because you basically do a full screen update at each op
Tommaso Cucinotta wrote:
Hi Abdel,
please find attached a first attempt of fixing the non-uniform scrolling
of LyX on trunk (21411).
Very good Tommaso! I know this represents a lot of work but there's
still some things to improve in your patch. I hope you won't let us down
:-). The downside
Great! Will try it out later today.
Stefan
Am 07.11.2007 um 00:04 schrieb Tommaso Cucinotta:
Hi Abdel,
please find attached a first attempt of fixing the non-uniform
scrolling
of LyX on trunk (21411).
Tommaso Cucinotta wrote:
Index: src/ParagraphMetrics.h
===
--- src/ParagraphMetrics.h (revisione 21411)
+++ src/ParagraphMetrics.h (copia locale)
@@ -113,6 +113,7 @@
InsetDims inset_dims_;
};
+
} // namespace l
Hi Abdel,
please find attached a first attempt of fixing the non-uniform scrolling
of LyX on trunk (21411).
Summary of benefits:
-) scroll is uniform and predictable when using the scrollbar, independently
of the contents (text, maths, very tall maths or pictures or tables,
ecc...)
-) scroll
47 matches
Mail list logo
