Rendering rectangles speed issue

[macbeth]

Thanks for your answer, Jacek.

Well, I counted myself that 200x200 rectangles cover approx 2500-times larger area than 4x4 rects. (Thank God it doesn't take 2500-times longer than drawing 250 000 4x4 rects, it would take more than 4 hours...)

And to count up to 1x10^10 takes around 1 minute on my machine, but that's not really the point. I was surprised, that although the rectangles were already drawn and visible on the widget, the cpu load remained high (which, of course, does not happen if I draw on a pixmap or image). I was wondering what is graphicsview doing all the time...

Well, the reason I wanted to draw on GraphicsScene/GraphicsView was, that it has vector representation of the scene and you can easily zoom, print to ps/pdf etc.
But the true (and point) is, that I have to rasterize the image somewhere along the process, so drawing on a pixmap is probably a better choice, after all.

I was just impressed by the R-project and it's fast plotting and wondering how to plot with comparable speed, but it is probably using some smart optimizations... (I know, I know, mr nobody saw something somewhere and wants the same magic in his lousy app)

Once again, thanks for your advice and explanation, Jacek...

[jacek]

Well, I counted myself that 200x200 rectangles cover approx 2500-times larger area than 4x4 rects. (Thank God it doesn't take 2500-times longer than drawing 250 000 4x4 rects, it would take more than 4 hours...)

Suppose that you want to draw those 200x200 rectangles on a 1280x1024 screen. Statistically every pixel would be coloured around 7600 times. Imagine how big speed up you would get just by removing the occluded rectangles.

I was surprised, that although the rectangles were already drawn and visible on the widget, the cpu load remained high (which, of course, does not happen if I draw on a pixmap or image). I was wondering what is graphicsview doing all the time...

Maybe it was redrawing the scene after adding every single rectangle?

I was just impressed by the R-project and it's fast plotting and wondering how to plot with comparable speed, but it is probably using some smart optimizations...

I don't have R at hand currently. Have you tried to make it draw those 250 000 rectangles?

[macbeth]

Suppose that you want to draw those 200x200 rectangles on a 1280x1024 screen. Statistically every pixel would be coloured around 7600 times. Imagine how big speed up you would get just by removing the occluded rectangles.

Well, that's true. Maybe counting the area that is covered by those rects and then drawing it using some drawing primitives would be faster, but that was not exactly what I was looking for, that example with 200x200 rects was just a try.
As I mentioned somewhere in first post, I wanted to draw barplot with, many rectangles, which overlap, but they are, of course, so thin, that they probably overlap each other only in 1 pixel area (and that means, that every pixel is redrawn 10 000's times probably). I'll try to draw it as lines or one looong path instead to see if it won't take less time. (Let me explain, that I want so much speed because I need my plot to resize with the widget, so the user experience (and my professor experience ) would not be very pleasant, if he had to wait 30secs on every resize)

Maybe it was redrawing the scene after adding every single rectangle?

Don't have any idea. The rects were added in less than 0.1 seconds to the scene, their rasterization took about 30secs, but I have no idea what is going on afterwards. Maybe the graphicsView is checking which rectangle is under mouse cursor and donig some pre-selecting (searchnig that BSP tree?) But that probsbly does not make sense, because the cpu load is that high even though the window is covered by other windows, so it has no reason to repaint itself...

I don't have R at hand currently. Have you tried to make it draw those 250 000 rectangles?

c<-seq(1:250000);
 
system.time(barplot(c));
[1] 0.772 0.120 1.928 0.000 0.000

c<-seq(1:250000);

system.time(barplot(c));
[1] 0.772 0.120 1.928 0.000 0.000

To copy to clipboard, switch view to plain text mode 

Which means user CPU, system CPU, elapsed time, and 2x time consumed by child processes... (I know it's not the same as 250 000 time 200x200, but still it is tremendously fast...)

[jacek]

Don't have any idea. The rects were added in less than 0.1 seconds to the scene, their rasterization took about 30secs, but I have no idea what is going on afterwards.

Could you prepare a minimal compilable example, so I can test it too?

[macbeth]

Of course, just slightly modified portedcanvas example -- try to add rectangle using Edit menu (or Alt + R), it should draw +-100 000 rects (some of them maybe cut out) quite fast, but afterwards the cpu load remains high (according to top or KDE task manager), on my machie around 90%...

here is an archive
just try to run qmake && make/gmake on it, it should be compiled & able to run...

and let me know how it works on your machine...

And thank you for the fruitful discussion

[jacek]

On my machine it uses around 30% when idle, but when I drag items over the rectangles CPU utilization jumps to 70%--80% (according to top). I've commented out three lines in main() and now it uses less than 1% when I don't touch the items. Finding which lines should be commented out I leave to you

[macbeth]

Well, I don't know what to say. I was searching for a timer in all other cpp files and did not find anything, supposing that main is just usual app.exec()... but as sherlock holmes said, if you foreclose all other possibilities, it must be the last one, even if it's almost improbable.

Sorry, sometimes I don't see what's in front of me...

And thanks, once more...