LowLevelGraphicsContext questions -


i’m implementing the LowLevelOpenGLRenderer, and i’m encountering some limitations in the interface. I’ve done about a half of the pure virtuals (except the one with gradient fills), but i’m unable to find where are the lowlevel virtuals for stroking a path.
i can only see ->fillPathWithXXX() functions and not ->strokePathWithXXX() ones, ah, also without the possibility to change the line width for the stroke…
in fact actually i can fill a path in the opengl component, but any call to graphics->strokePath () will produce a void in the opengl context…
where are those functions ?

other question, i would like to try painting some controls over the opengl context, to try how pricesely i’m implementing the low level renderer: but the Component::paint method is protected so i can’t call it deliberately… how can i call that explicitly without changing the juce code ?


There’s no need for a stroke command - strokePath just calculates the outline and calls fillPath to draw it.

And you can use Component::paintEntireComponent to explicitly draw it to a context.


ah oke, anyway i use GL_LINE_STRIP for stroking paths in conjunction with glLineWidth() for specifying thickness, and use GL_POLYGON for the fills (that’s the way OpenGL works).
sure i can use GL_POLYGON for drawing edges also, but i always see my path filled instead of being edge traced, even when strokePath is called…
thanx for the tips, i’'ve missed Component::paintEntireComponent before :wink:


any chance to have the Text drawing routine implemented in the LowLevelContext instead of being implemented in Graphics class itself ?


It’s something I’ve pondered over for a long time - there are some advantages and disadvantages to doing that…


yeah i can see the advantages, but which are disadvantages ? can’t see any
(but probably i missed the point)…

having them in low level, separated from the Graphics implementation could lead to have “complete” interchangeble drivers. Actually i’m drawing Components directly over OpenGL, but then i can’t draw any text…


The main difficulty is that you’d have separate mechanisms to draw the text and to measure it position and layout, so it could end up with things not quite matching up correctly.


yeah, but then if the text drawing routines are delegated to the low level class, only the low level class should know about text sizes and positioning: any higher level classes should ask the low level to get those informations. otherwise the low level graphics driver isn’t of much use if it is not completely replaceable…