On Thu, 2006-11-02 at 07:59 +0100, Asger Ottar Alstrup wrote: > Martin Vermeer wrote: > > On Wed, Nov 01, 2006 at 11:36:08PM +0100, Asger Ottar Alstrup wrote: > >> [Partial refresh requires partial coord cache refresh] > > > Hmmm, I don't think this is done in 1.4, and still single par update > > works just fine there... > > I guess that in the common case, things work out correctly because the > coordinates and sizes of insets are corrected when drawn. I can imagine > that the problem can occur when you delete insets without triggering a > full refresh. In that case, the coord cache would contain obsolete > references to deleted insets, which is a recipe for trouble. Of course, > the problem disappears at the next refresh, so in practice this might > not cause too much trouble. > > > in 1.5 the infrastructure is there but it isn't > > working properly, as whole-screen updates have been layered on top of it > > with reckless disregard for what was already there, which thus is now > > completely useless. > > There was no partial refresh before the meeting in Denmark either. You > have to search further back to find when it was disabled.
Yes I did... around r14456 "le 14e Juillet" by Abdel. > > I am a bit angry about this. It would have been so easy to see what > > exactly is getting rendered using the PAINTING debug flag. > > > > What about first getting the old singlepar/singlerow functionality back > > into a working state? Then we can see what is missing and provide it. > > See above. Do we want to take the risk? If we did in 1.4, we might as > well in 1.5, but why not try to implement partial coord cache refresh > while you are at it? I don't object... feel free to volunteer :-) Note that the job will be easier if stale caches are not covered up by the current overzealous full-screen refresh behaviour. I suggest getting rid of that first. (And consider that, in a typical typing situation, screen -- or rather, displayed text -- refresh work has an overkill ratio of _thousands_ of percents right now... in what other product than software would one get away with such inefficiencies? We're lucky that both Linux and Windows appear to have plenty of spare capacity here. OSX is the canary in the mine.) > Regards, > Asger Regards Martin
signature.asc
Description: This is a digitally signed message part
