[Kst] Kst2DPlot brainstorming

[George Staikos]

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 
iteration now.

   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.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/