Summary: | Maximize plot (Z) has become awfully slow | ||
---|---|---|---|
Product: | [Applications] kst | Reporter: | Nicolas Brisset <nicolas.brisset> |
Component: | general | Assignee: | kst |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | 2.0.0 | ||
Target Milestone: | 2.0.0 | ||
Platform: | unspecified | ||
OS: | Microsoft Windows | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Nicolas Brisset
2010-01-07 18:00:03 UTC
SVN commit 1073794 by netterfield: don't redraw plots/curve that are masked by maximizing another plot. BUG: 221687 M +3 -1 libkst/vector.cpp M +0 -1 libkstapp/cartesianrenderitem.cpp M +6 -2 libkstapp/plotitem.cpp M +2 -1 libkstapp/plotitem.h M +5 -0 libkstapp/plotrenderitem.cpp M +2 -1 libkstapp/view.cpp M +4 -0 libkstapp/view.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1073794 Sorry Barth, but there must be something else. I have just done a fresh compile (under Windows) and it still exhibits the same slow behavior. Maybe there was more than one issue? Or you haven't committed the complete fix? I have just tested on a (much) faster computer, and I don't notice the lag there. On the slower computer, loading the test file takes a good 10 seconds until I see the plots. Maximizing one plot is not far from taking as much time, while I mean it used to be much faster (though now that I'm wondering, I can't really be sure). Anyways, I mean it *should* be faster, even it wasn't before :-) Please specify -OS & hardware -Test details: number of plots number of samples data source type -timing results If possible, please include complementary test results from kst1.x This bug was reopened, but with no specifics, which makes it hard to fix or close. Please specify.... Yes, I know. I'm late, but I haven't come around to it lately. On my fast Linux machine I can compile very fast, which makes it ideal for testing, but I can hardly notice the problem. On the slow Windows machine, compiling takes ages but the problem is obvious. I have to take some time to investigate that in more detail. I'll try to let the compilation run in the background while I do something else... So, with today's svn version and a completely fresh and clean build, this seems to be acceptable again. Maybe at some point I tested with an unclean build, it seems I have been bitten by that a number of times lately. Sorry for the noise... I'll close this report now. Change version from 2.0.0_devel to 2.0.0 to simplify version numbering. These bugs are solved with 2.0.0 |