PDA

View Full Version : Limitations to QPolygonF?



roband915
13th March 2011, 11:52
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);
}


And on this line it crashes in MyScene.cpp


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

mitch
24th May 2011, 02:42
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
24th May 2011, 09:34
"it crashes"?

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

MarekR22
24th May 2011, 10:39
Is there any limitations to how many points a QPolygonF (http://doc.qt.nokia.com/latest/qpolygonf.html) 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
24th May 2011, 10:51
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
24th May 2011, 10:53
You have a curve not a list of all points of screen! So consider lines not planes!

stampede
24th May 2011, 10:55
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
24th May 2011, 11:46
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
24th May 2011, 12:19
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
24th May 2011, 12:35
Drawing tools should use a QPainterPath rather than QPolygonF. Then you can easily simplify the path.

SixDegrees
24th May 2011, 14:00
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
24th May 2011, 14:11
And on this line it crashes in MyScene.cpp


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


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
24th May 2011, 15:55
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).