[Development] New repository request for an accelerated 2D drawing module

Kaj Grönholm kaj.gronholm at qt.io
Tue Nov 11 07:24:17 CET 2025


So the decision has been made!

The name will be "Qt CanvasPainter" and the repository: qt/qtcanvaspainter

Br,

- Kaitsu -

________________________________________
From: Stan Morris <pixelgrease at gmail.com>
Sent: Thursday, 6 November 2025 17.49
To: Tuukka Turunen
Cc: Kaj Grönholm; development at qt-project.org
Subject: Re: [Development] New repository request for an accelerated 2D drawing module

Canvas is good. It works well for how QNanoPainter is used.

On Thu, Nov 6, 2025 at 06:03 Tuukka Turunen via Development <development at qt-project.org<mailto:development at qt-project.org>> wrote:
Since there was a question on names for the new item…

Canvas sounds good to me. It should be quite well understood and descriptive for this type of a component. Especially as it is very much like html canvas like Kaj said.

Yours,

                                Tuukka





Confidential
From: Development <development-bounces at qt-project.org<mailto:development-bounces at qt-project.org>> on behalf of Kaj Grönholm via Development <development at qt-project.org<mailto:development at qt-project.org>>
Date: Wednesday, 5. November 2025 at 13.27
To: development at qt-project.org<mailto:development at qt-project.org> <development at qt-project.org<mailto:development at qt-project.org>>
Subject: Re: [Development] New repository request for an accelerated 2D drawing module

> [I hope the hive mind here can find a better name for this than “Compact”, which I think is a rather subjective term that doesn’t say much. It’s faster - for certain use cases; it will have some API limitations compared to QPainter; it might or might not be smaller in terms of binary size and/or runtime footprint. It will grow over time, and then become less compact.

> We don’t want to use QRhi* for this family of classes and types, because that’s a very low-level namespace.

> One term that has been established for this kind of rendering is “Immediate”. While using that directly might be a bit too much of a nod towards ImGui (and generally the expectation that the framework doesn’t manage any state), a decent synonym for that is perhaps “Direct” (which is then again a bit close to Microsoft terminology…). Both indicate that the rendering bypasses (or doesn’t bother with) the scene graph data structures.

---

Hi,

I'm not set on "Compact", so it can be changed if we find more suitable naming scheme.

"Immediate" would probably associate too much to immediate mode GUI pattern as you say. And this isn't exactly "direct" as there are APIs to paint into path or texture, which retain the painting data on GPU. Or maybe that's just my interpretation of the word direct.

Compact here refers mostly to more compact API (compared to QPainter) and sets expectations: Prioritize simplicity and performance over features. If QC[ompact]Painter doesn't support feature X and we feel it would not fit well to a rather thin layer on top of QRhi, consider using "full" QPainter instead.

One of my earlier thought was "Canvas", as the API follows closely HTML Canvas 2D Context specification, ported to Qt C++. As one of the future plans is to reimplement Quick Canvas element using this backend, could be logical for that to use "Qt Canvas Painter".

But we could also use some fun / marketing name. Class names currently start with QC*, so if the name happens to start with C that may reduce the renaming needs but that's not a biggie ;-)

Br,

- Kaitsu -
--
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development
--
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development


More information about the Development mailing list