Limitations to QPolygonF?

[roband915]

Is there any limitations to how many points a QPolygonF can contain?
I have in my scene several polygons and when I use my "drawing tool" to draw some lines it crashes. But It only crashes when I add a polygon which contains 130188 points to be exact. If I don't add it everything works just fine.
I only uploaded the sourcefiles so it will not compile due to some dependencies I haven't included but I thought it would be better than printing whole classes in the thread?

This is how I populate the scene in graphicView.cpp

for(int i=0;i<shp.getPolygons().size();i++)
{
   MapLine* t = new MapLine(shp.getPolygons()[i]);
    scene->addItem(t);
}

for(int i=0;i<shp.getPolygons().size();i++)
{
   MapLine* t = new MapLine(shp.getPolygons()[i]);
    scene->addItem(t);
}

To copy to clipboard, switch view to plain text mode 

And on this line it crashes in MyScene.cpp

QList<QGraphicsItem*> test = currentDrawItem->collidingItems(Qt::IntersectsItemShape);

QList<QGraphicsItem*> test = currentDrawItem->collidingItems(Qt::IntersectsItemShape);

To copy to clipboard, switch view to plain text mode 

[mitch]

Sorry, I don't know how to answer .... for the moment, but I have a little question for someone who play with polygonitems: is it possible to make polygonitems whith no line between last and first point? an "open polygon"

thanks

[SixDegrees]

"it crashes"?

How? What does it do? What error messages are displayed?

[MarekR22]

Is there any limitations to how many points a QPolygonF can contain?
I have in my scene several polygons and when I use my "drawing tool" to draw some lines it crashes. But It only crashes when I add a polygon which contains 130188 points to be exact. If I don't add it everything works just fine.

130188 point for polygon it's a lot! Note that you want to have more points then screen resolution! Definitely first you should optimize you code and prevent adding dummy points (quick calculation: lets say users can drew a curve with speed 10 points per second, to draw curve with 130188 points 3.6 hours is needed, so something is wrong with you code or problem explanation!).

[SixDegrees]

130188 point for polygon it's a lot! Note that you want to have more points then screen resolution! Defenatly first you should optimize you code and prevent adding dumy points (quic calculation: lets say users can drew a curve with speed 10 points per second, to draw curve with 130188 points 3.6 hours is needed, so something is wrong with you code or problem explanation!).

It's nowhere near "screen resolution" if by that you mean the number of pixels on the screen. A very low resolution 600x800 screen has 480000 pixels; a more typical 1000x1800 screen has almost two million. Both have far more than the number of points in the OP's polygon. And in terms of drawing speed, even low performance graphics hardware is capable of rendering hundreds of thousands of points per second, if not millions.

The size of the polygon, then, almost certainly is not the issue. Knowing the actual error message would help to pin down what's going on, but couple hundred thousand points shouldn't be any trouble for even a small system.

[MarekR22]

You have a curve not a list of all points of screen! So consider lines not planes!

[stampede]

130188 point for polygon it's a lot! Note that you want to have more points then screen resolution!

That's right, but only if you have a 300x400 (or less) screen resolution
I agree with MarekR22, that count of points is impossible to be managed by human manually.
Are you adding new point each time a mouse is moved, when selecting this "polygon tool" ? If yes, then I'd suggest some optimizations, for example, there is no need to have two points in distance of 2 pixels to each other, it's just impossible for human to note such small gap. Define some kind of threshold value for minimal distance between two points for your drawing tool, I'm sure the count of points will be significantly reduced.

[SixDegrees]

Actually, polygons of this size and larger are quite common in GIS and other applications. Pruning may be beneficial at wider "zooms", but that sort of optimization needs to be performed by the rendering engine, not on the data itself, in order to support close-in zoom levels.

I have no idea what the OP is trying to do, just pointing out that without further information it isn't possible to say anything about whether the number of points is excessive or not. Just as it isn't possible to offer much in the way of help without knowing more about what the problem actually is.

[MarekR22]

1. Ok, but I marked key word "drawing tool". In this kind of application this number of points is just unexpected and must be result of bug in code.
2. Even if this application would be some GIS kind, before drawing number of points should be adjusted to current resolution for perfomance resons. Most of maps use 3 or more sets of data for different zoom factor for performance reasons and prevent user information flooding.

[wysota]

Drawing tools should use a QPainterPath rather than QPolygonF. Then you can easily simplify the path.

[SixDegrees]

1. Ok, but I marked key word "drawing tool". In this kind of application this number of points is just unexpected and must be result of bug in code.
2. Even if this application would be some GIS kind, before drawing number of points should be adjusted to current resolution for perfomance resons. Most of maps use 3 or more sets of data for different zoom factor for performance reasons and prevent user information flooding.

What kind of application? The OP doesn't say, and there's nothing posted that provides any clue.


QGis, which is written in Qt, routinely handles polygons containing hundreds of thousands of points and does so quickly and well. I seriously doubt that a few hundred thousand points is going to bog down any drawing routine, nor does that have anything to do with the actual problem, which is some sort of unspecified crash.

There's no point wasting time chasing an optimization that has nothing to do with the problem at hand.

Drawing tools should use a QPainterPath rather than QPolygonF. Then you can easily simplify the path.

As noted above, simplifications like this are the job of the rendering engine. Futzing with the data contained in the polygon would be the wrong approach, even if this had something to do with the problem at hand.

[nightghost]

And on this line it crashes in MyScene.cpp

QList<QGraphicsItem*> test = currentDrawItem->collidingItems(Qt::IntersectsItemShape);

QList<QGraphicsItem*> test = currentDrawItem->collidingItems(Qt::IntersectsItemShape);

To copy to clipboard, switch view to plain text mode 

Sorry, it can not open the tar.gz (file invalid?!), but some guesses:

Are you sure, that currentDrawItem is valid?
Maybe the 130188th point is somehow invalid? Did you check that?
Are you using Threads, that could mess something up?

[wysota]

As noted above, simplifications like this are the job of the rendering engine.

If the data comes directly from the user's input as is interpreted as free-hand drawing then I don't agree. Simplification is part of pre-processing this user-input.
I understand that you mean a situation when the core of data are points themselves (like when determining a map route) and not the "stroke" where the points are only control points (like with free-hand drawing).