Re: Still problems with tables
> btw. what do people say... can I begin the ripping? Uh... I would not mind if mathed was not the only semi-functional area ;-) It's always nice to have company. Andre' -- André Pönitz . [EMAIL PROTECTED] C++-Programmierer gesucht ... Naeheres unter http://mathematik.htwm.de/job
Re: Still problems with tables
On 4 Apr 2001, Lars Gullik [iso-8859-1] Bjønnes wrote: > I won't do anything (major) woth LyXParagraph before we begin ripping > out hte old !NEW_INSETS stuff. > > btw. what do people say... can I begin the ripping? > are we stable enough? > do things more or less work? How about a prerelease before ripping stuff out? And maybe we should include a warning that Mathed is known to have some problems. Allan. (ARRae)
Re: Still problems with tables
On Wed, 4 Apr 2001, Angus Leeming wrote: > On Wednesday 04 April 2001 16:19, Juergen Vigna wrote: > > On 04-Apr-2001 Angus Leeming wrote: [QSpriteField] > > > Ok, I know that this would be very sophisticated rendering, but is it > > > totally unfeasible? > > > > Well I wouldn't say unfeasible just "hard to realize". But that's the > > way we have to go for the ultimate performance. For now I just do what > > I can do to make it faster. > > ;-) Sure > > However, if there any Qt boffiins out there who think that we should change > to Qt for the default GUI, this is the first real example I can think of of > why Qt would be useful. As opposed to just pretty. > > Pure flame bait of course! Or Rasters Evas or the Gnome canvas or any other canvas that minimises the redrawing required. I'm not sure how well they handle tables or even how they'd handle this situation with an internal table column getting wider but I'm sure any of them would do better overall than the workarea currently does. There are some pretty fancy algorithms for deciding what to redraw I'd rather we didn't have to reimplement them ourselves. Evas seems like it should work with most frameworks/toolkits for X and is pretty fast. It also makes use of OpenGL (eg. Mesa) if it's available so you can have sprites and textures and other weird stuff. > Angus (who's had a good day at work and is feeling obnoxiously smug and who > furthermore enjoyed Henner's reminder of these little signatures!) Copycat. Allan. (ARRae) You won't catch me using one of those closing signatures. No siree. Not one.
Re: Still problems with tables
Juergen Vigna wrote: > I noticed it now, here it happens ALWAYS if the tabular is scrolled to the > right (if it's larger then the screen). I'll have a look! If the table is broader than the screen, there is another problem that you have probably noticed as well. If you start filling the last column, at the moment the table becomes larger than the screen, the table is repainted a couple of times. On a slow machine, you notice that the table is shifted to the left and right again and again - a clear indication for several redrawings (at least 6, I guess). I think one time should be enough, shouldn't it? Maybe a lot of needless redrawings are not noticed because the table stays at the same position on screen. But with a large table, you can see what is actually going on. There are some other strange things happening with figure floats that may be interesting to the other LyX developers as well: - If you insert a table into an empty float, two cursors are shown at first. One inside the table, one outside. - There is no caption any more. Has this to do with Lars newinset stuff? I thought it is not activated by default... - If you insert a caption, it first says "Figure #" and turns into "senseless" as soon as you enter some text below and above. (It doesn't change back if you delete the text afterwards) - Text selection with the cursor keys works correctly, but selecting text with the mouse doesn't work (the start of a selection does not change, i.e. you cannot get rid of a previous selection) Kind regards, Michael -- == Michael Schmittphone: +49 451 500 3725 Institute for Telematics secretary: +49 451 500 3721 Medical University of Luebeck fax: +49 451 500 3722 Ratzeburger Allee 160 eMail: [EMAIL PROTECTED] D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de ==
Re: Still problems with tables
On Wednesday 04 April 2001 16:19, Juergen Vigna wrote: > On 04-Apr-2001 Angus Leeming wrote: > > > perhaps this isn't very useful, but I seem to remember Warwick Allison wrote > > a qspritefield class in Qt to address just this type of problem. Ie, most of > > the view remains invarient but some section moves. In your case the quadrants > > of the table not including the active row/cell are not changed, but they just > > translate. It seems really sad that all calculations regarding their > > redrawing must be repeated. > > > > Ok, I know that this would be very sophisticated rendering, but is it totally > > unfeasible? > > Well I wouldn't say unfeasible just "hard to realize". But that's the > way we have to go for the ultimate performance. For now I just do what > I can do to make it faster. ;-) Sure However, if there any Qt boffiins out there who think that we should change to Qt for the default GUI, this is the first real example I can think of of why Qt would be useful. As opposed to just pretty. Pure flame bait of course! Angus (who's had a good day at work and is feeling obnoxiously smug and who furthermore enjoyed Henner's reminder of these little signatures!)
Re: Still problems with tables
On 04-Apr-2001 Angus Leeming wrote: > perhaps this isn't very useful, but I seem to remember Warwick Allison wrote > a qspritefield class in Qt to address just this type of problem. Ie, most of > the view remains invarient but some section moves. In your case the quadrants > of the table not including the active row/cell are not changed, but they just > translate. It seems really sad that all calculations regarding their > redrawing must be repeated. > > Ok, I know that this would be very sophisticated rendering, but is it totally > unfeasible? Well I wouldn't say unfeasible just "hard to realize". But that's the way we have to go for the ultimate performance. For now I just do what I can do to make it faster. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ We are drowning in information but starved for knowledge. -- John Naisbitt, Megatrends
Re: Still problems with tables
> Well you won't believe it but if you make the tabular large enough you > can see it's slow even on a Pentium 800 with 256Mb of RAM :( > We should enhance this and I'm looking on this, but right now I only get > small steps in that direction, but don't see a overall performance boost! Jürgen, perhaps this isn't very useful, but I seem to remember Warwick Allison wrote a qspritefield class in Qt to address just this type of problem. Ie, most of the view remains invarient but some section moves. In your case the quadrants of the table not including the active row/cell are not changed, but they just translate. It seems really sad that all calculations regarding their redrawing must be repeated. Ok, I know that this would be very sophisticated rendering, but is it totally unfeasible? Angus
Re: Still problems with tables
Juergen Vigna <[EMAIL PROTECTED]> writes: | I'm concentrating on InsetText right now so I cut the following questions | and leave them to someone else (Angus for xforms I guess and Lars for | LyXParagraph ;) I won't do anything (major) woth LyXParagraph before we begin ripping out hte old !NEW_INSETS stuff. btw. what do people say... can I begin the ripping? are we stable enough? do things more or less work? -- Lgb
RE: Still problems with tables
On 02-Apr-2001 Michael Schmitt wrote: > Hi, Hi Michael! > I intend to go on your nerves again :-) No way, just go on reminding me to have a look at this! > Now if you start scrolling either by moving down from > one table cell to the next with the cursor keys or by using the > scroll bar of the LyX window, the screen output becomes corrupted Ok I see this too! > I also noticed that changing the cursor position by clicking the > left mouse button does not work under all circumstance. Even though > I cannot provide a precise description of how to reproduce the bug, > it should be easy to observe if you play around with the table. Well I don't notice this right now! > If the cursor is at the beginning of a table cell (not inside the > red box) and I start typing, the whole table is redrawn. For > large tables (even if only a small portion is visible on screen) > this takes a second (on a Pentium 120). Is the cell empty? The whole tabular has to be redrawn ALWAYS if the width of a cell changes! If the width remains equal then it should draw only the cell in question. So did the width change or not? (Well only the visible cells are really redrawn, but that can be a lot!) > I would also like to point out that the performance is rather poor when > entering text in a table cell. In particular, the first character in a > previously empty table cell appears with a little delay. Sometimes, > characters are even swallowed by LyX because it cannot handle them in > time! (Maybe you should produce a little background load on your machine > in order to feel what I feel when using my old Laptop :-)) Well you won't believe it but if you make the tabular large enough you can see it's slow even on a Pentium 800 with 256Mb of RAM :( We should enhance this and I'm looking on this, but right now I only get small steps in that direction, but don't see a overall performance boost! > When leaving a table, the cursor is always moved in front of the table, > even though the user moved it past the end of the right-bottom table cell. Not if you exit with the MoveToRight Cursor key ;), but ok this should be changed/fixed! I'm concentrating on InsetText right now so I cut the following questions and leave them to someone else (Angus for xforms I guess and Lars for LyXParagraph ;) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ "Marriage is low down, but you spend the rest of your life paying for it." -- Baskins
