[Qt-interest] fastest way to draw everchanging pixels

[Sean Harmer]

Hi,

Reto Glauser wrote:
> wow, I'm really impressed. It took me a while to write my initial mail to the
> list trying to figure out how to explain my problem so I don't say too much but
> yet enough others understand it. Now, either I succeeded or you're just really
> good at understanding other people. Either way - you really solved EXACTLY what
> I've been trying to do. I couldn't resist trying your demo code just now (even
> though it's well past midnight) and well, it rocks. I did not dare hoping that
> your suggestion really will make that kind of a difference - but it does. 
Yes it is a useful tip to remember. Not only does it vastly reduce the 
number of function calls and the pushing and popping of the call stack 
it also allows the QGraphicsView framework to make its own 
optimisations. In the case where you also end up using a QGLWidget this 
will allow the driver to issue large batches of primitives to the 
hardware in one go which again reduces the work that the driver has to 
do and reduces pipeline stalls in the hardware itself since most 
graphics accelerators are designed to operate on many primitives 
simultaneously.
> The drawing is blazingly fast! Wonder if I can sleep now or will have to re-model my
> code ;-).
>   
Ah, the good old late night coding syndrome. :-)
>> I mean to maintain an array of molecules and an array of walls. Then implement 
>> a function to update their positions. Then after their positions have been 
>> updated simply make one call to draw the molecules and one more call to draw 
>> the walls. Something like the attached. The important parts are:
>>
>> ...
>>
>> As you can see we only make 5 calls to QPainter to draw the entire scene 
>> including setting the custom pens for molecules and walls.
>>
>> The attached app creates 50000 molecules and 1000 walls and initialises them 
>> to random positions. We then set off a timer to update and re-draw the scene 
>> every 40ms. On a 2.4GHz Core 2 Duo this uses approx 22-25% of the CPU.
>>
>>     
>
> Yeah, at last I got your suggestion. I was merely wondering if changing the
> position of a QPointF (e.g. setX()/setY()) will not add up CPU time as well.
>   
Well you have to update the position somehow and I suspect (not checked 
the Qt source code) that those functions will be very simple inline 
functions and so will be no different to direct array access anyway (in 
the presence of a half-decent compiler).
> Anyway, the dream of a poster - you get a demo within the day which does exactly
> what you've been trying to do. THANKS!
>   
You're welcome :-)
>> I'm guessing that your modelling code will be a little more complex than my 
>> dummy version in here :-) However if you are running on a multi-core machine 
>> there will likely be some benefit to doing the modelling updates in a worker 
>> thread. If you do this then I would advise you to refactor the example code so 
>> as do separate out the modelling from the drawing (good idea anyway).
>>
>>     
>
> Yeah, that's what I did. The modelling code is highly optimized and done in a
> worker thread.
>   
Ok that's good. So you shouldn't have too much to do to combine your 
modelling with the example drawing code I posted.
>> I have added comments on what to do to enable this to use OpenGL updates to 
>> squeeze a little more performance out of your machine if you can use it.
>>     
>
> THAT too is really great. I almost noted in my post that I'm looking for a
> solution which will (later) work with OpenGL too - THANKS again!
>   
No problem it's only one new line in the .pro file and 3 lines in the 
source. Not a big price to pay for hardware acceleration :-)
>> HTH a little,
>>     
>
> No, not a little - this is really amazing. Thanks Sean, I really mean it.
>   
No problem at all. It was fun. Out of interest what are you aspects of a 
gas are you actually modelling? Is this for a school/uni project or 
commercial?
>> Sean
>>
>> ps If your walls are really line segments then you would be better off storing 
>> them as QLineF's and calling QPainter::drawLines().
>>     
>
> Point taken. I'm new to Qt but you really give me a good base to do my work.
>   
That's good. If you run into any more problems just post to the list 
again and I'm sure that someone will be able to nudge you in an 
appropriate direction. Good luck with the rest of your project.

Sean