[Kst] Kst2DPlot brainstorming
staikos at kde.org
Sat Oct 8 20:16:20 CEST 2005
On Friday 07 October 2005 20:43, Barth Netterfield wrote:
> On October 7, 2005 04:38 pm, Ted Kisner wrote:
> > It seems to me that one way to split this up is the following:
> > 1. Move all the time related functions to a separate KstTime class or
> > something similar.
> > 2. Move all mouse/key handling to an external class. This will also
> > make it more portable when we want to use it for Kst3DPlot in the future.
> > 3. So Kst2DPlot will still be responsible for drawing the axes, plot
> > labels, grid, and legend. It will also call on all the basecurves to
> > paint themselves.
> I think part of the reason they are all together is that these tasks share
> data to such a large extent.
Just because they need access to eachothers' data doesn't mean they can't
be separated. Many of the things in there are conceptually different. They
may be related, but they're still two different things stuck in the same
place. It's horribly (-horribly-) difficult to work in Kst2DPlot now.
> > -----------
> > For healpix support, all that would be needed is a very simple and
> > general vectorfield basecurve. All the projection, gridlines, etc would
> > be taken care of.
> > So what do you all think- am I crazy? :-)
> The problem is a very thorny one, and we are just scratching the surface of
> the problems that are to be faced, I fear. I think that 2D plot is a beast
> at least as much because of the complexity and inherent interconnectedness
> of the the problem as because of bad planning.
Yes, it is a very large problem in general. I'm much more interested in
incremental changes at this point since we won't lose focus on the features
we need to implement, and we won't have any unpleasant surprises in terms of
stability or performance.
However I do think that the fact that Kst2DPlot is so complex is a result
of the implementation, as opposed to the implementation being a result of the
complexity. I think that as it is refactored, it will become much less
complex in terms of implementation. The history of this code is quite
interesting. It was once far more encompassing than it is now. I simplified
it when I created the view object code, but it became a dumping point for new
features that were at a level below Kst2DPlot. In retrospect, it might have
been worth the effort of fully rewriting it back then, saving another
I'm also very happy that we have this new rendering system because I'm
borderline tempted to change our rendering altogether. X11 is just not good
enough for what we need to do, and I'm starting to get convinced that we need
to turn our canvas into a gl widget and use OpenGL to do our rendering. I
think it's safe to say that we have suitable GL implementations everywhere
that Kst is used. After a long battle with X11 and discussions with X11
developers, I think the performance situation on X11 is ~hopeless in the
short term. We can get close to good performance, but I think there will
always be issues.
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/
More information about the Kst