[Qgis-developer] qgis pre-refresh rendering ?

[Martin Dobias]

On Sat, Dec 13, 2014 at 9:15 PM, Sandro Santilli <strk at keybit.net> wrote:

> On Sat, Dec 13, 2014 at 08:42:40PM +0700, Martin Dobias wrote:
> >
> > The extent of canvas items (in map units) stays the same, just the
> position
> > and bounding rect (both in screen coordinates) change accordingly when
> > zooming/panning.
>
> What's exactly the "bounding rect" ? How's it different from rect" ?
> Documentation doesn't say:
>
> http://qgis.org/api/classQgsMapCanvasItem.html#a8be640ba5958ed63df3a17a9c9b9792a
>
> http://qgis.org/api/classQgsMapCanvasItem.html#ad0cd631ace28e2feb63166d28b704364
>
> From QT documentation I understand "bounding rect" is the outer bounds
> of the item:
> http://qt-project.org/doc/qt-4.8/qgraphicsitem.html#boundingRect
>
> From QGIS code I see that the parameter passed to setRect() is in
> map units and is used to set a mItemSize member which is then used to
> compute the output from boundingRect(), thus effectively "setRect()"
> involves changing the "bounding rect" too. But "rect()" returns a
> different value than "boundingRect".
>

The Qt framework uses pos() and boundingRect() to understand where the
items are located in the scene (QGraphicsScene). These are all screen
coordinates - one can tell from the use of QPointF instead of QgsPoint
(always used for map / layer coordinates).

The rect() and setRect() is just our added convenience functionality in
QgsMapCanvasItem. The idea was that you just use setRect() to specify the
item's position+size in map coordinates - and the pos() and boundingRect()
will be set according to that. In addition, calls to updatePosition() from
map canvas make sure that pos() and boundingRect() are kept in sync with
changes to the canvas.

Some canvas items use that functionality (e.g. QgsRubberBand or
QgsMapCanvasMap) and don't worry about the screen coordinates. For some
items this default behavior is not useful, so they do not use setRect() and
provide their own implementation of updatePosition() and boundingRect().
For example QgsVertexMarker, which is centered on a map coordinate, but its
bounding box is independent from map coordinates / scale.

The design a bit clumsy I know... It would make more sense to have base
class QgsMapCanvasItem without any setRect() and without default setPos()
calls and boundingRect() implementation. And then have a derived class e.g.
QgsMapCanvasMapCoordsItem with those extra facilities - so when someone
would be creating a new item, they could decide which base class is more
appropriate.


> > Once rotation enters the picture a simple QgsRectangle is not enough
> > > anymore to express what area is shown in the canvas item. That is,
> > > the canvas item output rectangle is not a rectangle in map coordinate
> > > space. Could the "rect" concept be changed to something different then
> ?
> > > Like a triplet: center,resolution,rotation ?
> >
> > I don't think such triplet would work here well - we need to know the
> exact
> > bounds of canvas items (in screen coordinates) so that the underlying Qt
> > framework knows when it needs to repaint the individual items.
>
> Only the visible bounds or the full item bounds ?
> In other words, are these "bounds" independent of canvas size in pixels ?
>

The bounds are in screen coordinates = pixels.


> Why should canvas items keep rotation? Lots of canvas items do not care
> > about the rotation - and should not care, e.g. a cross marker should
> always
> > have the same appearance regardless of any map rotation.
> >
> > It is also worth noting that not all canvas items do need to have the
> > position + bounding box calculated automatically from map coordinates.
> For
> > example, annotations only have one point fixed to a map coordinate, the
> > rest of the bounding rect is defined in screen coordinates (independent
> > from map).
>
> Good point. So then why do we have this function at all:
>
>   void QgsMapCanvasItem::setRect( const QgsRectangle& rect )
>
> Which seems to take the "rect" in map coordinates ?
> (according to the internal use of toCanvasCoordinates method)
>

Hopefully this is now clear from the notes above. The items that do not
depend on "rect" in map coordinates can just ignore the existance of
setRect() and provide their own implementation of updatePosition() and
boundingRect().



> >
> > The map rotation functionality in the end is probably more complex than
> it
> > seemed to be. QEP explaining all the implications would be quite useful.
>
> Indeed, I greatly understimated it.
> I'll try to draft a QEP.
>

Thanks.

Cheers
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20141213/fb1075cc/attachment-0001.html>