[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: seeking QGraphicsView wisdom
From:       Jason Harris <kstars () 30doradus ! org>
Date:       2006-05-29 14:21:28
Message-ID: 200605290721.28828.kstars () 30doradus ! org
[Download RAW message or body]

On Friday 26 May 2006 00:34, Andreas Aardal Hanssen wrote:
> On Thursday 25 May 2006 17:55, Aaron J. Seigo wrote:
> > > (2) Is it feasible to extend QGraphicsView such that it uses a
> > > spherical coordinate system, rather than a rectilinear one?  Are the
> > > transformation and clipping functions exposed in the API?
> >
> > that i'm not sure about. i don't think so, however. andreas hanssen could
> > answer authoritatively on this, however. ergo the CC =)
>
> QGraphicsScene is strictly rectilinear, so if you want
> spherical coordinates, you probably need to maintain both
> coordinate systems, and map your spherical coordinates (and
> transformations) to rectilinear ones.
>
> I cannot imagine an API that provides an abstract coordinate
> system ;-). If you can come up with one, I'm all ears!
>
Wouldn't you just put the transformations into a function that can be 
subclassed?  Your transformations in QGraphicsView assume that the Data 
coordinate system is a rectilinear coordinate system, so your transformations 
will just involve a global rotation and a linear scale factor (probably 
implemented with a matrix transformation).  You could put this into a pair of 
functions:

virtual QPointF toScreen( const QPointF &DataPoint );
virtual QPointF fromScreen( const QPointF &ScreenPoint );

(I've assumed that QGraphicsView "knows about" the scale and rotation, so you 
don't need to pass them as arguments)

Then I could subclass KStarsSphericalView from QGraphicsView, and override 
these functions to do the data-to-screen transformations that I need.  Would 
it impact the performance of QGraphicsView to make the transformations a 
function call like this?

Assuming the transformations can't be abstracted in this way, then our only 
alternative would be as you say: we have to transform to rectilinear 
ourselves, and then populate the QGraphicsView item tree with the 
rectilinearized coordinates.  However, we have to re-project every time the 
center position is changed, so we'd be constantly repopulating the item tree 
in QGV.  I guess this would slow things down quite a bit.




-- 
KStars: http://edu.kde.org/kstars
Community Forums: http://kstars.30doradus.org
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]