Client blit in Qt

[Luc4]

Hi! I was reading this guide and I see they are talking about "client blit". Can someone explain what is it for and if it is possible using it to have both OpenGL and QWS on the screen (assuming I can provide a EGL native window)?

Thanks!

[high_flyer]

Can someone explain what is it for and if it is possible using it to have both OpenGL and QWS on the screen (assuming I can provide a EGL native window)?
Thanks!

In the link you posted is stated that:

It is recommended that Qt for Embedded Linux is configured with the -DQT_QWS_CLIENTBLIT and -DQT_NO_QWS_CURSOR options for optimum performance. OpenGL is rendered direct to the screen and these options prevent Qt for Embedded Linux from trying to do its own non-OpenGL compositing on the QGLWidget contents.

[Luc4]

Problem was that I needed the cursor. But I tried and in fact that definition is not necessary. Anyway, is there anyone able to explain in more detail what client blit is? I suppose it implies rendering somewhere in the memory and copying everything to the screen. Whereas, without blit operation, Qt would write directly on the screen. Is this correct?
Do you know of any place where I can get some more information on how Qt implements this?
Thanks!

[wysota]

My guess is that a client blit means that is the client (the app) that does the blitting instead of QWS (the server).

[Luc4]

Oh... Is blit performed by Qt in any case? Blit implies a copy of blocks of data for each update right?
And what is the difference then when blit is performed by the clients instead of by the server? Why is it necessary to let QWS and EGL surfaces to coexist?
Another question: I noticed client blit reduces the performance. Why?
Thanks for the information! This is very interesting!

[wysota]

Oh... Is blit performed by Qt in any case?

It's performed by Qt in both cases. The difference is where the blit happens.

And what is the difference then when blit is performed by the clients instead of by the server?

Read high_flyer's response (or the docs he points to) again, the answer is there.

Why is it necessary to let QWS and EGL surfaces to coexist?

QWS does its own compositing but since OpenGL usually paints its whole viewport (so the widget is opaque) there is no point in trying to compose it with what's painted below again. At least that's my guess, I've never used this functionality myself.

Another question: I noticed client blit reduces the performance. Why?

I would expect it to improve performance in some cases and reduce it in others.

[Luc4]

Sorry, but that document is not sufficient to answer some questions that I have in mind. What I'm not understanding is how these two works.

Without client blit I understand each surface redraws itself in some place of the graphic memory. After that, the QWS server performs the compositing and the necessary blocks of data are copied to the area of memory where the screen is placed. Is this correct, more or less?

With client blit, each surface redraws itself in some area of the graphic memory, and after that what happens? How can each surface know what part of itself has to be placed on the screen? I suppose anyway that the reason why this is necessary for OpenGL to work is that OpenGL draws directly to the screen, and if the blit was performed by the QWS server, it would require raster data.

Is, more or less, what I said correct?
Thanks for your help!

[wysota]

Sorry, but that document is not sufficient to answer some questions that I have in mind. What I'm not understanding is how these two works.

Then have a look at the source code.

Without client blit I understand each surface redraws itself in some place of the graphic memory. After that, the QWS server performs the compositing and the necessary blocks of data are copied to the area of memory where the screen is placed. Is this correct, more or less?

Yes, more or less.

With client blit, each surface redraws itself in some area of the graphic memory, and after that what happens?

I'm assuming the current state of the backbuffer is first copied to the client space if needed and then the currently drawn area is blitted onto it and then copied to the backbuffer again (or the client blits directly into the framebuffer).

How can each surface know what part of itself has to be placed on the screen?

I don't understand your question.