Fulvio wrote:
Hi!
> I always have the tree windows opened when using scid.
> I have two problems:
> 1) Sometimes it get stucked leaving me with a waiting mouse icon
> 2) I need to wait that the current search ends to move to another position
Agree on this point.
> I want to correct that
Great! :)
> and would like to have your opinions on which
> behavior is better.
> When the user want to move back or forward and the tree windows is still
> busy:
> 1) cancel the current search and starts the new one
> 2) schedule the new search but ends the current search too
>
> My preference went to 2, considering that so results are computed and
> cached.
Giving the fact that the reference base in question might be a several
millions base where all this searching takes a while I tend to go for 1,
as 2 might be quite slow.
Still, there might be an issue here with how the fill cache function
works. I don't think that there is a side effect but you should be
careful not to break it. The other function that might have a side
effect is "Fill mask with base" as this would currently also create a
nice cache for a mask and this is actually desirable, I think. And at
least fill mask seems to work by just moving through a game in autoplay.
I'm not sure about how fill cache is implemented. As far as I understood
it you need to jump to each relevant end position, that's why
treecache.dat looks like
{}
{1.e4}
{1.e4 e6}
{1.e4 e6 2.d4}
{1.e4 e6 2.d4 d5}
{1.e4 e6 2.d4 d5 3.exd5}
and so on.
> For example i can scroll fast the first 10 moves of a game, so when i
> come back i have an instant cached result.
> However i'm trying this solution but it's a bit weird: until all the
> searches are ended results unrelated to the current position on the
> board are displayed and you can't click on the tree windows to select moves.
I think, that the user should definitely see what he expects to see
right away that's why I think your option 1 would be nearer the mark.
Additionally, you'll not always want to fill the cache. If you can pull
his search to the front and move the other ones to the back it would
probably be ok, but I'm not sure about this scenario. In my actual
gameplay I've games in several stages where I switch to and fro. Some in
the opening where the tree is very helpful and should be updated, some
in the middle or endgame where ther're just no games anymore. Do you see
an automatic way to prevent Scid from continually updateing the tree here?
--
Kind regards, / War is Peace.
| Freedom is Slavery.
Alexander Wagner | Ignorance is Strength.
|
| Theory : G. Orwell, "1984"
/ In practice: USA, since 2001
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
