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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
