On Mon, Jun 09, 2003 at 11:26:41AM +0100, Angus Leeming wrote:
> Differences between Alfredo's patch and my suggested change? I don't
Oh sorry.
> believe you. I reckon that you are comparing this to the situation
> without any patch at all.
Yes.
regards
john
John Levon wrote:
> On Sun, Jun 08, 2003 at 07:10:27PM +, Angus Leeming wrote:
>
>> > So this change will
>> > tipically avoid an unecesary check and speed up things when
>> > navigating
>>
>> and the speed up is how big exactly ;-)
>
> Physically noticable. Getting accurate metrics is some
On Sun, Jun 08, 2003 at 07:10:27PM +, Angus Leeming wrote:
> > So this change will
> > tipically avoid an unecesary check and speed up things when navigating
>
> and the speed up is how big exactly ;-)
Physically noticable. Getting accurate metrics is somewhat tricky.
regards
john
Alfredo Braunstein wrote:
> I don't agree... The name is likely to be always valid (except for an
> incomplete frontend, that shouldn't be used anyway).
Really? "fork", "preamble" ?
> So this change will
> tipically avoid an unecesary check and speed up things when navigating
> with a dialog ope
Alfredo Braunstein wrote:
> John Levon wrote:
>
>> Please do, it looks like we can regain a few percent from this
>
> Does this betters out things... and uh... is correct? (Angus please check)
>
> Regards, Alfredo
Looks good except for this:
> Index: frontends/Dialogs.C
> Dialog * Dialogs::f
John Levon wrote:
> whitespace horkage, it all got converted to spaces. Applied with -l,
> testing now
Uh... sorry. (Damn knode. Used to work.)
Regards, Alfredo
On Thu, Jun 05, 2003 at 09:26:40PM +0200, Alfredo Braunstein wrote:
> Does this betters out things... and uh... is correct? (Angus please check)
Seems to be significantly faster in the "move the cursor along" test
regards
john
On Thu, Jun 05, 2003 at 08:43:40PM +0100, John Levon wrote:
> > Does this betters out things... and uh... is correct? (Angus please check)
>
> None of it applies to my tree for some reason...
whitespace horkage, it all got converted to spaces. Applied with -l,
testing now
john
On Thu, Jun 05, 2003 at 09:26:40PM +0200, Alfredo Braunstein wrote:
> Does this betters out things... and uh... is correct? (Angus please check)
None of it applies to my tree for some reason...
john
John Levon wrote:
> Please do, it looks like we can regain a few percent from this
Does this betters out things... and uh... is correct? (Angus please check)
Regards, Alfredo
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/c
On Thu, Jun 05, 2003 at 06:52:27PM +0200, Alfredo Braunstein wrote:
> This is probably what it's happening. I've pointed out the problem some time
> ago (and Angus pointed out the solution)... but then I forgot about this.
> I've had 0 time lately, but if you have some patience I will look again a
John Levon wrote:
> Angus: it seems something really dumb is happening with the
> params2string stuff :
>
> 08124398 2930 1.1519 lyx.bak LyXTabular::Write(Buffer const*,
> ostream&) const
>
> That's literally just moving the cursor about the table. Are we
> constantly refilling a close
On Thu, Jun 05, 2003 at 04:38:11PM +0100, John Levon wrote:
> I thought I had done. Any resizing of text insets: resizing of the main
> window, resizing of a column to a fixed width, etc.
>
> I'd kind of assumed you'd done these basic tests before asking to
> commit the patch :(
In fact I did. Bu
On Thu, Jun 05, 2003 at 05:35:40PM +0200, Andre Poenitz wrote:
> > Resizing is indeed broken also.
>
> Care to explain what 'resizing' you mean?
I thought I had done. Any resizing of text insets: resizing of the main
window, resizing of a column to a fixed width, etc.
I'd kind of assumed you'd
On Thu, Jun 05, 2003 at 04:27:38PM +0100, John Levon wrote:
> On Thu, Jun 05, 2003 at 08:39:33AM +0200, Andre Poenitz wrote:
>
> > I've played around with it quite a bit, even with 'large' docs as the
> > UserGuide and have not found any loss in speed whatsoever.
>
> Moving the cursor down a 45-h
On Thu, Jun 05, 2003 at 08:39:33AM +0200, Andre Poenitz wrote:
> I've played around with it quite a bit, even with 'large' docs as the
> UserGuide and have not found any loss in speed whatsoever.
Moving the cursor down a 45-high table is approximately 33% slower (8
seconds instead of 6 seconds).
On Thu, Jun 05, 2003 at 05:03:56PM +0200, Andre Poenitz wrote:
> > Er, erm, you removed the entirety of the lyx text resizing ...
>
> What's 'lyx text resizing'?
resizeLyXText(). Same in reinit. MAybe you were just a bit over-eager
with the delete, but I expect this will completely break a lot o
On Thu, Jun 05, 2003 at 03:49:09PM +0100, John Levon wrote:
> On Thu, Jun 05, 2003 at 08:39:33AM +0200, Andre Poenitz wrote:
>
> > The attached patch removes InsetText::InnerCache and tells all users of it
> > that there is not anything valid in the cache (i.e. assume find(...) ==
> > end() and re
On Thu, Jun 05, 2003 at 08:39:33AM +0200, Andre Poenitz wrote:
> The attached patch removes InsetText::InnerCache and tells all users of it
> that there is not anything valid in the cache (i.e. assume find(...) ==
> end() and remove all other branches)
Er, erm, you removed the entirety of the lyx
Angus Leeming wrote:
> Looks good except for this:
>
>> Index: frontends/Dialogs.C
>> Dialog * Dialogs::find(string const & name)
>> {
>> - if (!isValidName(name))
>> - return 0;
>> -
>> std::map::iterator it =
>> dialogs_.find(name);
>>
>>
I'd like to get insettext/insettabular on par with the rest of insets/*
which I believe is in comparatively good shape nowadays.
The attached patch removes InsetText::InnerCache and tells all users of it
that there is not anything valid in the cache (i.e. assume find(...) ==
end() and remove all
21 matches
Mail list logo
