As LCLQt6 widgetset is ready, let's consider it

[Alexey-T]

e.g. here, bgraqtbitmap.pas

uses LCLType,
  LCLIntf, IntfGraphics,
  qtobjects, {$ifdef LCLqt5}qt5{$else}qt4{$endif},

[Alexey-T]

and here, bgrabitmap.pas

			{$IF defined(LCLqt) or defined(LCLqt5)}

2 lines like this.

[circular17]

Good to know.

[circular17]

Hi Alexey,

Do you have Qt6 installed to check if only adding the directive for it would function properly?

Regards

[Alexey-T]

Not adding a directive by hands, but adding the option in the LCL Project options: widgetset name.

[regs01]

I tried testvirtualscreen under Linux with Qt6, but it just won't redraw anything, unless full repaint is ticked on. And with full repaint it's very slow.

[circular17]

Thank you @regs01 for testing! Ok, so there may be some possible optimizations and would require some patches.

A first step would be that BGRAQtBitmap would be used. You can see it in bgrabitmap.pas unit. In the uses clause, in Lazarus code editor, units not selected by the directives are written with a semi-transparent color. The directives need to be modified. Up to now LCLqt is for Qt4, LCLqt5 is for Qt5. The new macro is LCLqt6 is for Qt6.

Then, we need to determine how to optimize for Qt. One way is to allocate an in-memory image with Qt and assign the Data pointer to its content. Another way is to use direct drawing functions to draw data directly on a canvas, instead of creating an image handle. This depends on what's available in Qt.

There is a QImage class that seems to provide a direct pixel access. It has a bits function that returns the data pointer. The QImage::Format_RGBA8888 format seems to be the most compatible with BGRABitmap, with only red and blue swapped compared to the default BGRA format.