[Interest] QOpenGLWidget and text

[Allan Sandfeld Jensen]

On Monday 06 April 2015, Matthew Woehlke wrote:
> On 2015-04-04 05:57, Till Oliver Knoll wrote:
> > Am 03.04.2015 um 17:26 schrieb Matthew Woehlke:
> >> On 2015-04-02 13:45, Till Oliver Knoll wrote:
> >>> ..... But what's next? A "drawButton"? "drawBitmap"? In a Widget?!
> >> 
> >> Yes. And why not?
> > 
> > Because the class name sais *Widget, and not *Painter or *WhateverItem.
> > 
> > A Widget's responsibility - much like the one of a View; we'll come to
> > that in a second... - is to provide a /surface/ to draw onto, and to
> > manage the underlying system resources (we'll deliberately skip over
> > other functionality, such as layout management).
> 
> Please don't be overly pedantic. The point isn't whether the ability is
> particularly a member of QOpenGLWidget, but whether it is available *at
> all* (in a non-deprecated class, anyway) without the user having to
> concoct a complicated system for providing it.
> 
> Hopefully Qt3D will bring back these features. It's still a shame that
> 5.4 gets left out in the cold.
> 
> > The important point to take away here is that a /Widget/ itself never
> > exposes functionality to /draw/ something (exceptions might prove my
> > thesis ;)). You may draw /onto/ a Widget - but /how/, that's the
> > responsibility of some other class.
> > 
> >> QGraphicsView already does this sort of thing.
> > 
> > It's funny that you mention that /View/ class, since it does exactly
> > /not/ "this sort of thing".
> 
> Actually it does. It does it via a helper class, but as above, that's
> not really the point. (And anyway, what I meant was 'the QGV-based
> graphics framework'.)
> 
> > That sounds to me you really want to look into Qt3D, if you want this
> > kind of convenience.
> 
> Well, yes, but doesn't help 5.4.
> 
> >> The problem is I don't *want* to draw "over" GL¹. I *need* to draw *in*
> >> GL, specifically I need to specify the text location in terms of the GL
> >> modelview space.
> >> ...
> >> Overpainting techniques are fine... *for overpainting*. That's not what
> >> I'm doing.
> > 
> > Clearly I cannot predict your application's requirements, but
> > "overpainting", that's exactly what you were doing apparently, all the
> > time. You said so yourself, you were using
> > 
> >  http://doc.qt.io/qt-4.8/qglwidget.html#renderText
> 
> True, and it does happen that the QGLWidget method is also technically
> overpainting. Fortunately for my use case, this was not an issue (the
> bit I'm drawing is itself an overlay, albeit a 3D one that needs to be
> rendered with GL), but for this case it would be technically preferable
> to actually rendering the text into the GL depth buffer (if unlikely to
> make a practical difference).
> 
> In fact that has been the case for every time I've used renderText (in
> multiple applications); I am drawing annotations *in GL world
> coordinates* that are expected to be visible 'on top' anyway.
> 
> > I've never used this method myself, but from what I gather you specify
> > the text coordinates in /window/ coordinates - /not/ world (or model)
> > coordinates!
> 
> That is *one option*, and not the one I use. Look again; there is an
> overload that takes *world* coordinates. This is the one I use, and I
> can assure you it works.
> 
> > You get exactly the same result (probably even a better one due to better
> > anti-aliasing) by using a QPainter and "overpaint" at the same window
> > coordinates.
> 
> Actually, not better; exactly the same :-).

So why not use a QPainter? 

QPainter p(qoglwidget);
p.renderText()?

`Allan