Fast painting scrollable widget

[bunjee]

Consider that the power of OpenGL comes from the fact that you actually stream commands into the GPU (in a specific order), which is sometimes tedious and prone to errors. We could say that this is Bad(TM) because it's low-level and doesn't allow much flexibility when writing the code. But it's just the way OpenGL works - it's optimized for performance and to get best performance, you need to stream commands into the processing unit.

I won't comment any further on this, we cannot really compare Opengl and Qt. What I was pointing out is the fact that what will make Opengl fast (or not ) is the number of triangles period. Not the fact that they're inside whatever signal based container.

Actually this is unfortunately not true. I've been talking to Trolls about this during DevDays and it looks like Aliens won't improve the speed of item-view index widgets. At least not in any significant way. Using delegates is still the preferred solution. I know that Trolltech is working on a better default delegate that would allow us to make some things in an easier fashion and they also work on a new generation item-views framework. So there is work around the subject, but it's hard to say when it will be available to public.

You've got to accept that : if we admit that the performance of widgets was partly slow because of the interactions / updates with the window manager now that Qt 4.4 is using Alien windows/widgets it should definitely be faster. It's written on the blog you linked us to.

Yes, in that situation the performance should be better.

Why would it be way faster in my case and not with the item view approach ? Layouts ? Well I'm using layouts.

As the name says Itemviews is oriented around items, not widgets, so it's not optimized for your case. It's like you wanted to implement an image viewer using QTextDocument. Sure it's possible, but there are better ways to do this.

Yeah that's definitely why I kept my approach. Delegates are not of any use in my case since my approach is to base everything on a layouted QScrollArea of widget.

Memory consumption should decrease with 4.4 and Aliens. But I doubt your problem is memory consumption. I think the problem is positioning the widgets - if you create and show a widget (or hide it) the layout of all widgets needs to be recalculated and that takes time with a vast number of widgets.

You make a point.
But, again, performance wise, if the QLayout was really optimized what would differenciate it from a listview of delegates ? If you insert / remove items you still have to recalculate the position of your painting area.

No, it will crash your application.

As we both agreed, I'm keeping my QScrollArea of QWidgets and I'm quite happy with it. When my widgets are loaded performance is good.
Now I have to think about how to load/unload as fast as I can.

In my case I've come to the conclusion that since one user cannot see more than a given numbers of rows at a time, it makes sense to thread the adding / removing of widgets using signals. As a result I would be streaming populating and de-populating a list.

And no if it's written correctly it shouldn't crash anything. Still if you have better solutions I'm interested as I'm still brainstorming about this.

Exactly. According to Marius (one of the Trolls responsible for Itemviews) the slowndown is caused by actually moving the widgets in the view.

Again, if it's well written I see no reason for that.

[momesana]

Maybe using QGraphicsView would be a middleway if the research going on around QGV-Layouts and QGV-Widgets bear fruit. I don't think this will be the case with Qt-4.4 but maybe Qt-4.5. Then we could have QPushButton clones with a similiar interface but made of standard QGraphicsItems providing both performance and ease of use, not to mention the eyecandy. The slides from Trolltech's DevDay were really interesting.

[wysota]

I won't comment any further on this, we cannot really compare Opengl and Qt. What I was pointing out is the fact that what will make Opengl fast (or not ) is the number of triangles period. Not the fact that they're inside whatever signal based container.

Well, that's the point - OpenGL is optimized for GPU performance, Qt is optimized for high level portable API. If you provide a high level API to OpenGL (like for example Coin3D), it will make it slower. Just the same like comparing C++ code and equivalent assembly code - the latter will be faster.

You've got to accept that : if we admit that the performance of widgets was partly slow because of the interactions / updates with the window manager now that Qt 4.4 is using Alien windows/widgets it should definitely be faster. It's written on the blog you linked us to.

The keyword is "partially" - in what portion? My guess is that the slowdown is not caused by updates (because widgets are not visible, so they shouldn't receive paint events), but by repositioning them. I don't know why they get repositioned (one can always look into the source code), but looks like they are - without using layouts, by the way. Another guess is that using "uniformItemSizes" should improve the situation a bit. If you want - just take a profiler and see what takes more time.

Why would it be way faster in my case and not with the item view approach ? Layouts ? Well I'm using layouts.

If you scroll a scroll area, the position of widgets inside the viewport doesn't have to be recalculated (the viewport is simply moved). This is not the case with item views - you need to calculate and reposition each of the item widgets. At least that's my guess after talking to Marius during DevDays.

Yeah that's definitely why I kept my approach. Delegates are not of any use in my case since my approach is to base everything on a layouted QScrollArea of widget.

Great. So we shouldn't talk about item views if you shouldn't have used them in the first place. If you don't need a model - why use a view? If you need a model, but not a view of items, why use an item view? Use a scroll area with a hand written controller (like QDataWidgetMapper)translating between the scroll area and the model.

But, again, performance wise, if the QLayout was really optimized what would differenciate it from a listview of delegates ?

There is no listview of delegates - there is a single delegate which paints multiple items. And only paints those that are actually visible - that's the main difference. It doesn't paint widgets. These are handled by the view itself.

If you insert / remove items you still have to recalculate the position of your painting area.

Yes, but you don't move anything, just redraw the canvas.

Now I have to think about how to load/unload as fast as I can.

Think about just hiding widgets instead of destroying them. You can keep a pool of invisible widgets and show them on demand.

In my case I've come to the conclusion that since one user cannot see more than a given numbers of rows at a time, it makes sense to thread the adding / removing of widgets using signals.

You can't operate on widgets from worker threads. This will result in a segfault sooner or later. Regardless of using signals for communication. You'd have to end up with manipulating widgets from the main thread anyway, rendering the whole approach useless.

And no if it's written correctly it shouldn't crash anything.

I'm sorry, but until Qt5 comes out you are wrong. Widgets are not thread safe. Period.

Again, if it's well written I see no reason for that.

Just try it and you'll see (believe me, I tried it with Qt3 and it was crashing like hell). Widgets rely on data structures that reside in the main thread. They trigger events, which need to be handled in the main thread. They paint to the screen, which again needs to be done in the main thread to prevent race conditions and simoultaneous access to the "frame buffer". There are probably more reasons.

Maybe using QGraphicsView would be a middleway if the research going on around QGV-Layouts and QGV-Widgets bear fruit. I don't think this will be the case with Qt-4.4 but maybe Qt-4.5. Then we could have QPushButton clones with a similiar interface but made of standard QGraphicsItems providing both performance and ease of use, not to mention the eyecandy.

I don't think this is the way to go. The poster really needs just a "list" of widgets, so using "items" (be it graphics view items or itemviews item) is a workaround for a problem that has a direct solution - QScrollArea.