Alfredo Braunstein wrote:
>> The situation is better now, but not perfect. Look for example at what
>> happens when using find/replace or spellcheck. Cursor size is not
>
> Right. The fix was to replace manual adjustment of cur.pit, cur.pos with a
> call to setCursor that does that + DEPM + setCu
Jean-Marc Lasgouttes wrote:
>> "Alfredo" == Alfredo Braunstein
>> <[EMAIL PROTECTED]> writes:
>
> Alfredo> Jean-Marc Lasgouttes wrote:
>>> Where is the relevant code? I guess that real_current_font, which
>>> is just a cache is not updated at this point (you get the size of
>>> Author par
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
Alfredo> Jean-Marc Lasgouttes wrote:
>> Where is the relevant code? I guess that real_current_font, which
>> is just a cache is not updated at this point (you get the size of
>> Author paragraph).
Alfredo> LCursor::getDim
>> So yo
Jean-Marc Lasgouttes wrote:
> Where is the relevant code? I guess that real_current_font, which is
> just a cache is not updated at this point (you get the size of Author
> paragraph).
LCursor::getDim
> So you may have to make sure it is updated.
Ah, ok. So we have to add a call to setCurrentFo
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>> Also, if you put the cursor in the middle of the first line and use
>> cursor down, just after jumping above the note inset the cursor
>> does not have the right size.
Alfredo> What should I put as cursor size? IMO it should be
Jean-Marc Lasgouttes wrote:
> Now that I test the right build %-] here is a small difference:
> when using cursor down, the cursor does not seem to enter float insets
> (see for example the first note of the user guide).
>
> In head, the behaviour is slightly better, since the cursor enters the
>
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
Alfredo> Anyways, I think that this may be one of the last regressions
Alfredo> of CoordBranch wrt HEAD, so I need testers to ascertain this
Alfredo> please...
Alfredo> Please report every other change wrt to HEAD
Now that I test
Andre Poenitz wrote:
> So lets think a bit about it.
>
> My stomach says "Full repaint is just fine". Most of the other time
> consuming stuff can be done in the metrics phase and cached (e.g. in
> MetricsBase or the position cache) if necessary. So metrics() is the
> part that hurts.
Are your s
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
Alfredo> Hummpff Jean-Marc. Check line numbers in rowpainter.C: this
Alfredo> backtrace is from HEAD, not CoordBranch.
Erm, sorry about that. I do not know how I managed this :) I'll try to
do a real test now...
JMarc
On Sun, Nov 21, 2004 at 08:07:58PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > We could e.g. have a 'metrics dirty flag' which is set to true
> > by default and in cases we know that we haven't changed anything (i.e.
> > just selecting and the creen hasn't moved) we set it to fal
On Sun, Nov 21, 2004 at 02:46:53PM +0100, Lars Gullik Bjønnes wrote:
> | Third time you repeat this nonsense. Who's rushing anything?
>
> Andre seems pretty eager.
Because ifrst of all, I think it's the right sthink to do technically,
and secondly, I see messages on lyx-cvs telling me that Alfred
Andre Poenitz wrote:
> We could e.g. have a 'metrics dirty flag' which is set to true
> by default and in cases we know that we haven't changed anything (i.e.
> just selecting and the creen hasn't moved) we set it to false.
Sure, but metrics is only one thing.
When selecting, the bottleneck is
On Sun, Nov 21, 2004 at 03:03:06AM +0100, Lars Gullik Bjønnes wrote:
> Just because it is better than head does not mean that we should rush
> to get it into head.
I disagree especially since needlessly maintaining the branch bites
into the most valuable resources we currently have: Alfredo's time
On Sun, Nov 21, 2004 at 12:48:52AM +0100, Alfredo Braunstein wrote:
> Mmm... I'm not 100% sure. The point is how to make these optimizations in a
> way that keeps the code clean ;-)
We could e.g. have a 'metrics dirty flag' which is set to true
by default and in cases we know that we haven't chang
Lars Gullik BjÃnnes wrote:
> coord might be better than what the head was lately, but it is not
> better than what head used to be.
I surely agree. (maybe we disagree with the dates: I think it is slow from
about when we changed the drawing scheme -- i.e soon after 1.3.)
I'm not as sure as Andre
Lars Gullik BjÃnnes wrote:
> PS. It is not friday today.
;-)
I got confused with the timezone change and all...
Alfredo
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>>
>> | Andre Poenitz wrote:
>>>
Hm... you could just merge CoordBranch back to HEAD. From wht I can tell
>>>
>> | Not all people here seem to agree.
>>
>> Just b
Lars Gullik BjÃnnes wrote:
> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
> | Andre Poenitz wrote:
>>
>>> Hm... you could just merge CoordBranch back to HEAD. From wht I can tell
>>
> | Not all people here seem to agree.
>
> Just because it is better than head does not mean that we should ru
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> Loading times is not the crux of everything.
>
| Of course not.
|
>> I think we must look at how much we redraw on update as well.
>
| I think that speed is mostly irrelevant at this stage (plenty of
| regressions)
Lars Gullik BjÃnnes wrote:
> Loading times is not the crux of everything.
Of course not.
> I think we must look at how much we redraw on update as well.
I think that speed is mostly irrelevant at this stage (plenty of
regressions). What I really cannot understand is this sudden rush to
address
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
>
>> Hm... you could just merge CoordBranch back to HEAD. From wht I can tell
>
| Not all people here seem to agree.
Just because it is better than head does not mean that we should rush
to get it into head.
--
Lgb
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Fri, Nov 19, 2004 at 01:47:33PM +0100, Alfredo Braunstein wrote:
>> > Humm... I don't see that here (in CoordBranch). Do you get every time, or
>> > only once in a while? Can you send a backtrace?
>>
>> This is important. I don't understand why could
Andre Poenitz wrote:
> Hm... you could just merge CoordBranch back to HEAD. From wht I can tell
Not all people here seem to agree.
> it is now uniformly better than HEAD.
I think so, also.
> "Strictly better", in fact.
>
> Me neither. Anywa, I think it's safe to promise that 1.4.0 won't be
On Fri, Nov 19, 2004 at 01:47:33PM +0100, Alfredo Braunstein wrote:
> > Humm... I don't see that here (in CoordBranch). Do you get every time, or
> > only once in a while? Can you send a backtrace?
>
> This is important. I don't understand why could we be drawing at such large
> coordinates. Are y
Hummpff Jean-Marc. Check line numbers in rowpainter.C: this backtrace is
from HEAD, not CoordBranch.
Alfredo
Jean-Marc Lasgouttes wrote:
> #7 0x0816a3f8 in Point (this=0xbfffde98, x=555, y=18953) at
> #coordcache.h:29
> #8 0x0816982b in CoordCacheBase::add(InsetBase const*, int,
> #int) (
>
Jean-Marc Lasgouttes wrote:
> Alfredo> This is important. I don't understand why could we be drawing
> Alfredo> at such large coordinates. Are you sure this is coordbranch?
> Alfredo> [btw, you don't happend to have a > 4000 pixels high monitor,
> Alfredo> do you?]
>
> I updated CoordBranch, rebu
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
Alfredo> This is important. I don't understand why could we be drawing
Alfredo> at such large coordinates. Are you sure this is coordbranch?
Alfredo> [btw, you don't happend to have a > 4000 pixels high monitor,
Alfredo> do you?]
I
Alfredo Braunstein wrote:
> Jean-Marc Lasgouttes wrote:
>
>> I took a quick look at CoordBranch and it seems to work well. I found
>> a few bugs that happen to be in HEAD too, but seems to be related to
>> what you are doing.
>>
>> - load Tutorial; Ctrl-End ==> crash
>>
>> Assertion triggered
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> Spring/Summer 2003...
>> Not that,m that helps
>
| Humm... so more or less right after releasing 1.3 (say before changing the
| drawing scheme)? Let's call this 1.3, not HEAD, mind you? ;-)
a bit later then perhap
Lars Gullik BjÃnnes wrote:
> Spring/Summer 2003...
> Not that,m that helps
Humm... so more or less right after releasing 1.3 (say before changing the
drawing scheme)? Let's call this 1.3, not HEAD, mind you? ;-)
Alfredo
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>>
>> | Well, this is something we should think about certainly. We do an update
>> | call on every MOTION event. I have some ideas to speed this up: for
>> | instance
Lars Gullik BjÃnnes wrote:
> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
> | Well, this is something we should think about certainly. We do an update
> | call on every MOTION event. I have some ideas to speed this up: for
> | instance we could update only when the cursor has actually changed
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Well, this is something we should think about certainly. We do an update
| call on every MOTION event. I have some ideas to speed this up: for instance
| we could update only when the cursor has actually changed position, or if
| that is not enough
Jean-Marc Lasgouttes wrote:
> I took a quick look at CoordBranch and it seems to work well. I found
> a few bugs that happen to be in HEAD too, but seems to be related to
> what you are doing.
>
> - load Tutorial; Ctrl-End ==> crash
>
> Assertion triggered in Point::Point(int, int) by failing
I took a quick look at CoordBranch and it seems to work well. I found
a few bugs that happen to be in HEAD too, but seems to be related to
what you are doing.
- load Tutorial; Ctrl-End ==> crash
Assertion triggered in Point::Point(int, int) by failing check "y < 4000" in
file ../../lyx-devel/
Georg Baum wrote:
> Assertion triggered in Point CoordCache::get(const LyXText*, int) by
> failing check "it != pars_.end()" in file ../../src/coordcache.C:42
> ?
> - some files are not rendered if loaded via commandline. The splash screen
> stays instead visible, but with a blinking cursor. Afte
Georg Baum wrote:
>> - a coordinates related crash related to mouse selection (hard to
> trigger -
>> please give me instuctions to get it if you can)
>
> Do you mean this one:
> Assertion triggered in Point CoordCache::get(const LyXText*, int) by
> failing check "it != pars_.end()" in file ../..
Am Donnerstag, 11. November 2004 17:05 schrieb Alfredo Braunstein:
> Current known bugs wrt HEAD:
>
> - a coordinates related crash related to mouse selection (hard to
trigger -
> please give me instuctions to get it if you can)
Do you mean this one:
Assertion triggered in Point CoordCache::get(
Andre Poenitz wrote:
> On Sat, Nov 13, 2004 at 09:02:58AM +0100, Alfredo Braunstein wrote:
> xforms has been sending strange events for quite a while. I think we
> stumbled across it already in Chemnitz, but fixing real LyX problems was
> somehow higher up in the list of priorities.
This may be a
On Sat, Nov 13, 2004 at 09:02:58AM +0100, Alfredo Braunstein wrote:
> Damn me, this bug is already in HEAD! Why didn't anyone say so? Any idea
> when was it introduced?
xforms has been sending strange events for quite a while. I think we
stumbled across it already in Chemnitz, but fixing real LyX
Alfredo Braunstein wrote:
> I finally had a look at why the xforms frontend is slower than qt in
> CoordBranch. For some reason, XWorkarea sends every PRESS event
> inmediately followed by an unexistent RELEASE event, even with wrong
> coordinates (negatives). THis explains why selection doesn't w
I finally had a look at why the xforms frontend is slower than qt in
CoordBranch. For some reason, XWorkarea sends every PRESS event inmediately
followed by an unexistent RELEASE event, even with wrong coordinates
(negatives). THis explains why selection doesn't work in xforms as well...
Now, I do
42 matches
Mail list logo
