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)

[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.