Rare error with line style

[avis_phoenix]

I write a program that draw lines, this program draws the entire line, the program works fine until you change the style of drawing the line, for example if the style is dotted; the program becomes increasingly unstable in this vertical line, what can I do?

[wysota]

Could we see some code?

[avis_phoenix]

I upload my all project, in eobjects.cpp in EObjects:aint put the instruccions for draw the line, the case 'b' (is lines) in subcase 'A' (this is the case with problem) in refresh calculate the points P1, P2 in case 'b' and subcase 'A' (in the second switch) if the source is very complicated then i will write a small project, sorry

[jpn]

I upload my all project, in eobjects.cpp in EObjects:aint put the instruccions for draw the line, the case 'b' (is lines) in subcase 'A' (this is the case with problem) in refresh calculate the points P1, P2 in case 'b' and subcase 'A' (in the second switch) if the source is very complicated then i will write a small project, sorry

The UI is in a foreign language. So... what should one do to reproduce the problem? I vote for a small test app.

[avis_phoenix]

Sorry ...
Here I put the small project without foreign languages (apologies), execute this program and move the points, after with the combination Ctrl + C changes the style of the line and see the error... Thanks

[Uwe]

I remember several bugs and performance issues with drawing lines in the history of Qt4. AFAIR they all were bugs/problems of the homebrewed raster paint engine. The raster paint engine is involved, when painting on Windows or when painting to a QImage on all platforms.

Without looking at your code it is important to know which OS and which Qt version you are using.

Uwe

[avis_phoenix]

Well, I use X11 (Ubuntu) and Windows, with Qt 4.3.2 (but this problem since I use Qgraphics items, in Qt 4.2... (I hope it was my mistake and it is easy to correct)

[Uwe]

Hm, after rotating the line some time the application gets slower and slower until it hangs ( Linux/X11 ) for some time. Looking (randomly) at the stack the application is busy inside QPainterPath::toFillPolygon, where it iterates over a polygon of 32513(!) pieces.
So this should be TrollTechs business und I recommend to file a bug report.

In the meantime:

a) Calculate the visible part of your line before(!) painting and do your QPainter::drawLine for this part only. The 32513 pieces indicate, that Arthur needs most of the time rendering stuff, that is not visible at all.
b) disable antialiasing, when you have a non solid line

HTH,
Uwe

PS: Try the code from clipLine in qpaintengine_x11.cpp

[wysota]

Comment out "setCacheMode ( QGraphicsView::CacheBackground );" from the view class. You don't have a background so there is no point caching anything. When you rem it out, the app works just fine.

BTW. Implementing shape() would also be advised.

[avis_phoenix]

Well, how should I write the bug report? Since i have no idea about how to write one.

[wysota]

But what do you want to report?

[avis_phoenix]

But even comment "setCacheMode (QGraphicsView: CacheBackground);" anyway freezes

[wysota]

You mean that if you take the code from this post
http://www.qtcentre.org/forum/p-rare...ostcount5.html
and comment out background caching, the code is still slow?

[avis_phoenix]

yes (when the line is vertical and don't solid style)

[wysota]

Hmm... could someone please verify this? The code works blindingly fast for me...

Edit: Indeed the code slows down if the line approaches a vertical direction. But this seems to be a problem related to the math used to calculate the line, not to redrawing the line inside graphics view.

Edit:
Seems you are trying to draw a line between such coordinates when it is vertical:
QPointF( -512 , -133155 ) QPointF( 512 , 110557 )

I'm not surprised the line is drawn so slow... Unfortunately improving the algorithm in Qt is very hard to achieve when the line is not solid, because the exact dash positions have to be calculated based on real (not culled) coordinates. Changing the equation here would help a lot.

Edit:
Your code is faulty... Never write such code:

if(p1.x()-p2.x()!=0)

if(p1.x()-p2.x()!=0)

To copy to clipboard, switch view to plain text mode 

if x() returns floating point values. Instead use a neighbourhood, like so:

if(qAbs(p1.x()-p2.x())>=0.1)

if(qAbs(p1.x()-p2.x())>=0.1)

To copy to clipboard, switch view to plain text mode 

The next thing to do is to provide a good implementation of shape() for the line, so that it doesn't have to be constantly redrawn when you move your mouse over the canvas.

[wysota]

I implemented an example app, that does more or less the same as yours. Notice, that it doesn't slow down the application when the line is vertical.

#include <QApplication>
#include <QGraphicsView>
#include <QGraphicsScene>
#include <QGraphicsEllipseItem>
#include <QGraphicsLineItem>
 
 
class DotItem : public QGraphicsEllipseItem {
public:
  DotItem() : QGraphicsEllipseItem(){
    setRect(-5,-5,10,10);
    setFlag(ItemIsMovable);
    QPen pen;
    pen.setWidth(2);
    pen.setColor(Qt::red);
    setPen(pen);
    m_line = 0;
  }
  void setLine(QGraphicsLineItem *l){ m_line = l; }
protected:
  QVariant itemChange ( GraphicsItemChange change, const QVariant & value ){
    if(m_line){
      QLineF l = m_line->line();
      QPointF oldPos = pos();
      QPointF p1 = l.p1();
      QPointF p2 = l.p2();
      if(oldPos==p1){
        p1 = value.toPointF();
      } else if(oldPos==p2){
        p2 = value.toPointF();
      } else return value;
      m_line->setLine(QLineF(p1,p2));
    }
    return QGraphicsEllipseItem::itemChange(change, value);
  }
private:
  QGraphicsLineItem *m_line;
};
 
int main(int argc, char **argv){
  QApplication app(argc, argv);
  QGraphicsView view;
  view.setScene(new QGraphicsScene(QRectF(-512, -512, 1024, 1024), &view));
  view.setRenderHints(QPainter::Antialiasing);
  DotItem *i1 = new DotItem;
  DotItem *i2 = new DotItem;
  QGraphicsLineItem *line = new QGraphicsLineItem;
  QPointF p1(-212, 212);
  QPointF p2(212, -212);
  line->setLine(QLineF(p1, p2));
  QPen pen;
  pen.setStyle(Qt::DashDotLine);
  pen.setWidth(2);
  line->setPen(pen);
  view.scene()->addItem(line);
  i1->setPos(p1);  i2->setPos(p2);
  view.scene()->addItem(i1);  view.scene()->addItem(i2);
  i1->setLine(line); i2->setLine(line);
  view.show();
  return app.exec();
}

#include <QApplication>
#include <QGraphicsView>
#include <QGraphicsScene>
#include <QGraphicsEllipseItem>
#include <QGraphicsLineItem>


class DotItem : public QGraphicsEllipseItem {
public:
  DotItem() : QGraphicsEllipseItem(){
    setRect(-5,-5,10,10);
    setFlag(ItemIsMovable);
    QPen pen;
    pen.setWidth(2);
    pen.setColor(Qt::red);
    setPen(pen);
    m_line = 0;
  }
  void setLine(QGraphicsLineItem *l){ m_line = l; }
protected:
  QVariant itemChange ( GraphicsItemChange change, const QVariant & value ){
    if(m_line){
      QLineF l = m_line->line();
      QPointF oldPos = pos();
      QPointF p1 = l.p1();
      QPointF p2 = l.p2();
      if(oldPos==p1){
        p1 = value.toPointF();
      } else if(oldPos==p2){
        p2 = value.toPointF();
      } else return value;
      m_line->setLine(QLineF(p1,p2));
    }
    return QGraphicsEllipseItem::itemChange(change, value);
  }
private:
  QGraphicsLineItem *m_line;
};

int main(int argc, char **argv){
  QApplication app(argc, argv);
  QGraphicsView view;
  view.setScene(new QGraphicsScene(QRectF(-512, -512, 1024, 1024), &view));
  view.setRenderHints(QPainter::Antialiasing);
  DotItem *i1 = new DotItem;
  DotItem *i2 = new DotItem;
  QGraphicsLineItem *line = new QGraphicsLineItem;
  QPointF p1(-212, 212);
  QPointF p2(212, -212);
  line->setLine(QLineF(p1, p2));
  QPen pen;
  pen.setStyle(Qt::DashDotLine);
  pen.setWidth(2);
  line->setPen(pen);
  view.scene()->addItem(line);
  i1->setPos(p1);  i2->setPos(p2);
  view.scene()->addItem(i1);  view.scene()->addItem(i2);
  i1->setLine(line); i2->setLine(line);
  view.show();
  return app.exec();
}

To copy to clipboard, switch view to plain text mode 

[Uwe]

But what do you want to report?

When using a non solid style Qt seems to split the line into pieces and to render them one by one. In the demo these were ~32000 pieces, what are too much (for fast rotations) to be antialiased in time on my low budget notebook ( the fan gets noisy and the application hangs ).

But considering that you can see < 100 dashes/dots on the viewport ( only a small part of the line is visible), you will agree, that Arthur could do the job much better by clipping the line before rendering.

I remember, that I was talking to the Trolls about introducing polygon clipping as an optional render hint before Qt4.0 was out: the main problem are the overruns, when the coordinates are mapped to X11 (= shorts). The Qt4 source includes the clipping algos, but obviously there is no API to make them available to the user.

Uwe

[wysota]

But considering that you can see < 100 dashes/dots on the viewport ( only a small part of the line is visible), you will agree, that Arthur could do the job much better by clipping the line before rendering.

If you have non-solid line, you have to calculate which points on the path are to be filled and which are to be left empty. So you have to go through the whole line and calculate it. The next step is to transform the line into a painter path and finally render the path to the device. I don't know at which point does the clipping occur (btw. clipping is supported on graphics view if you set a proper hint on an item), but if it occurs after the path is calculated, there is not much that can be done. With lines it is relatively easy to clip, but if you have a complex shape, you can't just guess where to clip.

The problem in this particular application is the wrong calculation of line coordinates. The scene is more or less 1000x1000, so having coordinates that range up to several thousand in both positive and negative values yields an item that is more or less 1000 times bigger than the whole scene. And it's needlessly redrawn many times because shape() is not implemented properly.

[Uwe]

I don't know at which point does the clipping occur ...

From the facts it's easy to say: at the wrong one. That's what a bug report is good for.

(btw. clipping is supported on graphics view if you set a proper hint on an item), ...

AFAIR the line was painted by QPainter from a homebrew item. In such a situation the hint gets lost in the GV framework and doesn't make it into the painting operation.

With lines it is relatively easy to clip, but if you have a complex shape, you can't just guess where to clip.

No, it's also easy to clip polygons ( f.e. Sutherland-Hodgman ) and most (all ?) shapes are ( or can be ) build from polygons. Believe me - I had to implement this all in Qwt.

The problem in this particular application is the wrong calculation of line coordinates. The scene is more or less 1000x1000, so having coordinates that range up to several thousand in both positive and negative values yields an item that is more or less 1000 times bigger than the whole scene.

Well, if you implement zooming you often run in similar situations.

Uwe

PS: Antialiasing of vertical lines is a nop. No surprise, that the performance is much better then.

[wysota]

From the facts it's easy to say: at the wrong one. That's what a bug report is good for.

But you can't just move clipping to another place without affecting other things, possibly even degrading capabilities or denying the whole paint engine concept.

AFAIR the line was painted by QPainter from a homebrew item. In such a situation the hint gets lost in the GV framework and doesn't make it into the painting operation.

I'm not sure we are talking about the same thing. I'm talking about QGraphicsItem::ItemClipsChildrenToShape - it can't be lost anywhere in a custom item, because it's enforced by a parent item. So it's enough to make a transparent item that spans the whole scene to introduce clipping to the scene bounds. But I'm not really sure if it gives any performance gain, because the slowdown is caused by making a polygon, not drawing it.

No, it's also easy to clip polygons ( f.e. Sutherland-Hodgman ) and most (all ?) shapes are ( or can be ) build from polygons. Believe me - I had to implement this all in Qwt.

Yes, but first you need to have these polygons. OpenGL is so fast because it doesn't have to generate polygons itself, it receives them from the "userspace". Here you have to transform the line to a polygon first before clipping and it is the transformation that takes time. That's what I meant about the place (or time) where clipping occurs - there would be a gain only if you clipped before transforming to polygons.

Well, if you implement zooming you often run in similar situations.

No, because regardless of the zoom level, the number of logical polygons (or painter path components) doesn't change. If you have a line consisting of 100 dashes, it will always be 100 dashes - if the zoom level is 1000% or 25% that doesn't really matter.

PS: Antialiasing of vertical lines is a nop. No surprise, that the performance is much better then.

It's not nop. A line has caps, caps may be shaped differently and that causes aliasing (at least the round cap does).
http://doc.trolltech.com/latest/qt.h...nCapStyle-enum

Furthermore Qt antialiasing is not only to remove the aliasing effect - it also softens the shape and vertical lines are affected by it - they appear thicker and blend into the background.