[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: T-Merge speed up by caching screened data

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Mon, 9 May 2011 08:46:49 +0200

On Sun, May 8, 2011 at 22:51, Oto BREZINA <otik_at_printflow.eu> wrote:
> Dear Stefan
> I'm not sure if mailing list is best platform to talk about this (bit
> slow), but anyway.
> Till now I:
>  * improve KANJI support
>  * cleaned UseThis, UseBoth ... code
>  * move text and block selection (back) to view coordinates
> What I would like to do:
>  * extend KANJI support finding way for proper wrapping for minimal
> speed cost (add option to select wrap engine in worse case)
>  * fix some wrapping issues - may need caching
>  * enable cursor even in read-only view - it do all staff you just
> don't see it
>  * editing both views in diff mode
>  * convert cursor to view-line coordinates
> This have cons and pros I have to check. Cursor can be more persistent
> over resizing and easier to use -  It can speed up or slow down system.
>  * cache data collected from/for screening
> This is main point of this email.
> What we have today is three views with view-data and Screened data cache
> in each. Then common Screen2View vector.
> If I leave fact that no all view are used all time - all views and
> screened data should have same size.
> Once I insert any line in any of view I have to do it with all views.
> For now this is handled by editing methods (UseLeft, PasteText ...). So
> first point is to instead of manipulating views vectors separately
> implement one common threeviewdata vector to handle this. I don't know
> how first compare (on load) is performed though.

Seems to be a good idea.

> After inserting line we have to rebuild screen2view and screened data as
> well. If we move screened data into threeviewdata vector we get screened
> data keept with their source even after line insertion a thus reduce
> need for rebuild.


> I don't know what lead you to current design so I like to share my long
> term plans to check it they don't collide with some of your design
> decision before I start.

TMerge has grown over time. The decisions at the beginning were ok,
but of course with more and more features added those decisions won't
hold up anymore.

> This whole thing may be separated class with its own file. Object itself
> may be placed in MainForm and shared or implemented as Singleton.
> Thoughts?

Depending on the object, I'd implement it as a singleton. But a member
of CMainForm would be fine too.


  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-05-09 08:47:12 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.