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 <[email protected]> on behalf of Kaj
Grönholm via Development <[email protected]>
Date: Wednesday, 5. November 2025 at 13.27
To: [email protected] <[email protected]>
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
[email protected]
https://lists.qt-project.org/listinfo/development
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
