Canvas is good. It works well for how QNanoPainter is used. On Thu, Nov 6, 2025 at 06:03 Tuukka Turunen via Development < [email protected]> 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 <[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 >
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
