## This time, I used a QPainter object in a very ordinary way, as would be done in genuine GUI-building.

One project which I have been posting about has been, my ongoing effort to teach myself how to use the Qt5 GUI Library, which professional programmers do use in order to design Graphical User Interfaces – GUIs – for applications / programs. In fact, in a preceding posting, I wrote that I had discovered a deliberately unusual way to use one of the object classes in Qt 5.7.1, so that a ‘QImage’ object could be rendered to the screen of a computer, without first having to be transformed into a ‘QPixmap’ object. The ordinary thing to do would be, to transform it thus, first.

That trick can increase performance if two situations are met:

• The graphical information could have started out as a bitmapped image, And
• That image could have been unusually large, so that to have to buffer the entire image in its uncompressed form several times, could pose a considerable drain on the amount of memory that even modern computers should part with.

But, when designing GUIs, the starting point of the graphical information can be, simulated brush-strokes, with a simulated ‘QBrush’ and ‘QPen’, that are orchestrated by a programmer to give logical meaning to his GUI (beyond just adding the predefined widgets to it). In that case, the trick which I just wrote about will not gain anything over what I am about to describe.

When the ‘QPainter’ object and session are initialized, their target can be a ‘QPixmap’ object, and, after a sequence of painting instructions has finished, it can be assigned to a ‘QLabel’ widget once, by way of the ‘.setPixmap()’ function, thus resulting in a custom widget. Much buffering takes place, and, if the code has been written correctly, the graphic appears on the screen. The following is the graphic which my latest exercise generated:

Admittedly, this does not correspond to the GUI of any real software. But hypothetically, it just as well might. In fact, ‘A Chess-Board’ is just as easy to construct, using the same methodology. Only, actually programming the computer to play Chess is a little harder.

The fact that I was able to post this graphic was partially due, to the added ability the Qt5 Libraries have, to Save a ‘QPixmap’ object, or a ‘QImage’ object, directly to the hard drive, using a simple, straightforward API, and to the format of a PNG File. That task is also achieved in the code sample I am about to link to.

The real caveat here is, Not to try doing funny stuff with the internal ‘.pixmap()’ pointer that belongs to the ‘QLabel’ object, because even though it can be done, writing to that internal property does not offer much in the way of performance improvements, when the goal is to design most GUIs.

(This is a link to the previous exercise.)

(Updated 8/21/2020, 21h25… )

## How to make a QLabel widget display a QImage object, without first converting it to a QPixmap.

I have been studying the Qt v5.7.1 GUI Library on a private, informal basis, and making progress. As I was doing this, I observed a fact which is generally thought to be true, but which may not always be so.

GUI Libraries such as Qt have a set of object classes defined, which allow geometries to be drawn onto an abstract surface that exists in software, such geometries being Ellipses, Arcs, Rectangles, Polygons, Polylines, Chords etc.. Under Qt5, this is performed by way of the ‘QPainter’ class, together with a ‘QBrush’ and a ‘QPen’ class, and one out of several subclasses of the ‘QPaintDevice’ class. The crux of the operation is, that the ‘QPaintDevice’ class’s subclass needs to specify some sort of pixel buffer, so that the classes ‘QPixmap’ and ‘QImage’ certainly qualify. Multiple other classes also work. These pixel buffers are necessary physically, for the abstract drawing surface to ‘remember’ what the painting operations left behind, in the form of an image.

But what anybody who incorporates this into their Apps’ GUI will want to solve next is, to display the resulting pixel buffer. And an ugly way to do that, which is often used, is to select the ‘QPixmap’ class as the target, and then to do something like this:


void MainWindow::resetQ()
{
delete sw_pixmap;
sw_pixmap = NULL;
sw_pixmap = new QPixmap(":/res/images/Unknown.jpg");
int width = size().width();
int height = size().height();
i_label.setPixmap(sw_pixmap->scaled(width - 20, height - 50, Qt::KeepAspectRatio, Qt::SmoothTransformation));
}



The main problem with this is, that temporary pixmaps are being generated as arguments to function calls, by what I call ‘Naked Constructor Calls’. The compiler will generate temporary objects, and pass them in to the functions being called. And, because those objects were allocated on the stack, as soon as the function returns, they are just popped off the stack, hopefully in a way that results in no memory leaks.

When such temporary objects are simply complex numbers, I can still live with that, But in this case, they are pixel buffers!

Actually, I bent the truth slightly here. The way the function ‘setPixmap()’ is really prototyped, it accepts its argument via a reference. If this were not the case, the code above would truly become ridiculous. However, because of the way arguments are nevertheless presented and then forgotten, the ‘QLabel’ object that called this function still needs to create an internal copy of the pixel map, and must also deallocate the memory once replaced. Further, the temporary object created by ‘sw_pixmap->scaled()‘ is in fact a modified copy of ‘sw_pixmap’, and the compiler sees to it, that it gets deallocated, after the containing function call has returned. Whenever (larger) objects are returned from function-calls by value, they are stored in a special region of memory, managed by the compiler. (:4)

There has got to be a better way, in certain situations, to display whatever pixel buffer was painted to, from a QLabel object. And there is.

(This is a link to the previous exercise.)

(Updated 8/20/2020, 17h10… )