On Tue, Mar 25, 2003 at 03:26:32PM +0100, Alfredo Braunstein wrote:
> > The mantra is: "fix size in the first phase, fix position in the
> > second".
>
> I was pondering a bit about this... and I don't understand very well how
> do you want to do things.
>
> My problem is the following: the firs
Alfredo Braunstein wrote:
> My problem is the following: the first phase for lyxtext right now is the
> rebreaking. In this phase rows are not separate entities. The lyxtext
> cannot determine it's size without knowing its own row positions. So a)
> there is a blurring between phases or b) as rows
Andre Poenitz wrote:
> I don't.
>
> The mantra is: "fix size in the first phase, fix position in the second".
>
> Andre'
I was pondering a bit about this... and I don't understand very well how do
you want to do things.
My problem is the following: the first phase for lyxtext right now is the
On Mon, Mar 24, 2003 at 03:32:54PM +, John Levon wrote:
> On Mon, Mar 24, 2003 at 04:16:47PM +0100, Andre Poenitz wrote:
>
> > Why?
>
> For positioning the cursor etc.
Either we want to position the cursor as a result of a mouseclick, so we'd
better have drawn something before - so this is a
On Mon, Mar 24, 2003 at 04:16:47PM +0100, Andre Poenitz wrote:
> Why?
For positioning the cursor etc.
> [Ok, maybe we need it _now_, but do we need it there in the long run?]
I think so
regards
john
On Mon, Mar 24, 2003 at 03:08:17PM +, John Levon wrote:
> > It should do so, but in the second phase, i.e when
> > RowPainter() soes its work.
>
> This has nothing to do with the second phase andre, we need the caching
> during the first phases.
Why?
[Ok, maybe we need it _now_, but do we n
On Mon, Mar 24, 2003 at 09:51:29AM +0100, Andre Poenitz wrote:
> > We were discussing the posibility of letting the row cache its y position as
> > well. What do you think about that?
>
> It should do so, but in the second phase, i.e when
> RowPainter() soes its work.
This has nothing to do wit
On Mon, Mar 24, 2003 at 09:12:39AM +0100, Alfredo Braunstein wrote:
> We were discussing the posibility of letting the row cache its y position as
> well. What do you think about that?
It should do so, but in the second phase, i.e when
RowPainter() soes its work.
Andre'
--
Those who desire to
Andre Poenitz wrote:
> On Fri, Mar 21, 2003 at 05:08:52PM +0100, Alfredo Braunstein wrote:
>> If not, I have the feeling that a better solution can exist, like O(1)
>> keeping only the y coordinate of one row.
>
> The row should cache its size, at it should be re-computed in the
> metrics() phase
On Fri, Mar 21, 2003 at 05:08:52PM +0100, Alfredo Braunstein wrote:
> If not, I have the feeling that a better solution can exist, like O(1)
> keeping only the y coordinate of one row.
The row should cache its size, at it should be re-computed in the metrics()
phase...
Andre'
--
Those who desi
On Sun, Mar 23, 2003 at 11:51:08PM +0100, Alfredo Braunstein wrote:
> An option would be to keep also the top_row in adition to the anchor_row.
> Pretty cheap (we compute it anyway).
Sounds good.
regards,
john
John Levon wrote:
> This could get complicated ... all I know is that O(n) across all the
> rows just to place the cursor is really very silly.
An option would be to keep also the top_row in adition to the anchor_row.
Pretty cheap (we compute it anyway).
Regards, Alfredo
On Sun, Mar 23, 2003 at 10:51:00PM +0100, Alfredo Braunstein wrote:
> Ok, but I'd wait for Lars rowlist patch.
When he finishes it ...
> scrolled tables yes. nested tables no. I've taken the userguide and started
> mangling it randomly without any problem. Not very methodic, as you see ;)
I don
John Levon wrote:
>> -I've removed all useless row->height(0) (done already by the ctor)
>
> Any chance you could make a separate patch for this (which could go in
> regardless) ?
Ok, but I'd wait for Lars rowlist patch.
>> -top_y() and top_y(int) are both called intensively by insets. I'm
>> r
On Sun, Mar 23, 2003 at 09:54:53PM +0100, Alfredo Braunstein wrote:
> Good idea. But anchor_row_ is not necesarily at the top of the screen now
> (it will be mostly the cursor row)
Ah, bugger, good point.
>... maybe we should go up and down from anchor_row_ simulaneously?
This could get complic
John Levon wrote:
> Start from anchor_row_. Most getRowNearY() calls are in responsible to
> cursor clicks etc. If you reach rowlist.end(), start from begin() until
> you reach anchor_row_ again.
Good idea. But anchor_row_ is not necesarily at the top of the screen now
(it will be mostly the curs
On Sun, Mar 23, 2003 at 08:58:50PM +0100, Alfredo Braunstein wrote:
> We are storing the positions of rows, so we have a cheap map from rows to
> positions, not the other way around.
> For getting getRowNearY to work faster we should have some way of doing
> binary search, something hard to do wit
> I guess I should read the patch and find out why getRowNearY won't work
> with it
We are storing the positions of rows, so we have a cheap map from rows to
positions, not the other way around.
For getting getRowNearY to work faster we should have some way of doing
binary search, something hard
On Fri, Mar 21, 2003 at 05:08:52PM +0100, Alfredo Braunstein wrote:
> I cannot see any performance difference at first sight (but John said that
> top_y() was a bottleneck, so I don't know).
Well, it was dwarfing the rest of the stuff in the profiles, that is
all.
> -I've removed all useless row
This patch adds book-keeping of the y coordinate of rows (as discussed on
the "top_y is killing us" thread).
I cannot see any performance difference at first sight (but John said that
top_y() was a bottleneck, so I don't know).
-I've removed all useless row->height(0) (done already by the ctor)
-t
20 matches
Mail list logo
