Which origin does FLTK draw function use ? Widget or Window?

[Fady Megally]

I'm trying to create a custom rpm gauge widget. everything looks fine when i test it by itself. But when i try to draw it at a different position in the parent window it seems to always draw using the origin of the window and not that of the widget no matter what x or y value i am passing to the constructor.

a printf() after calling the constructor confirmed that the widget "knows" the intended x and y.

Is this the default behavior ? i thought that the draw function uses the widgets 0,0 and not the window. do i need to explicitly call the x() and y() in the custom draw() function and apply transforms and/or offsets to correct this ?

[Ian MacArthur]

On Tuesday, 25 May 2021 at 07:31:02 UTC+1 fmeg... wrote:

Is this the default behavior ? i thought that the draw function uses the widgets 0,0 and not the window. do i need to explicitly call the x() and y() in the custom draw() function and apply transforms and/or offsets to correct this ?

Yes, all fltk drawing (in the 1.x series) is Window Relative, not Widget Relative.

The adjustment I usually use is, at the start of my draw() methods, do:

int xo = x();

int yo = y();

The add (xo, yo) to the root of any integer drawing I do.

I think, if you use fluid to generate a derived widget, you can also ask it to do that offsetting for you.

Or you can use the transform based drawing methods of course, which are handy for more complex scenes but can be slower than the basic integer methods, of course.

Greg as a nice demo of an Aircraft Altimeter widget here:

http://www.seriss.com/people/erco/fltk/#Altimeter 

Which I think embraces these issues (though TBH it is probably more elaborate than you really needs, since Greg was attempting to illustrate some more "advanced" techniques with that demo...)

 

[Fady Megally]

Ian

This was plenty helpful . Thank you !

I noticed that some drawing functions do not care about the current transform. I think fl_pie() is one of them. A fl_translate() call before it does not seem to affect the origin so i think will follow your method here by adding xo and yo to the parameters.

I did not know about the FLUID part so i will definitely explore that.

Will check out Greg's widget too. sure there is a lot to learn there

Thanks again 

[Ian MacArthur]

On Wednesday, 26 May 2021 at 03:01:35 UTC+1 fmeg... wrote:

I noticed that some drawing functions do not care about the current transform. I think fl_pie() is one of them. A fl_translate() call before it does not seem to affect the origin so i think will follow your method here by adding xo and yo to the parameters.

Yes - this is documented, https://www.fltk.org/doc-1.3/drawing.html#ssect_Fast so if you use the "fast" drawing methods they may or may not honour the transformation (it's platform and implementation dependent...) so best not to use the transformation in that case.

the "complex" shapes  https://www.fltk.org/doc-1.3/drawing.html#ssect_Complex should honour the transformation in all cases, but will be a bit slower to render in most circumstances (though probably not enough to matter unless the scene is very involved.)

 

I did not know about the FLUID part so i will definitely explore that.

Will check out Greg's widget too. sure there is a lot to learn there

Or do what I do, which is check Greg's examples first, in case he already has one that does what I need...

 

Also, as a side note, the posting style around here is *not* to top-post. So please post below, with replies interleaved with the citations to which they refer, and preferably trimmed to remove any extraneous clutter, so as to keep the conversation as clear as possible.

Thanks.

[Fady Megally]

 Roger that. will stick to that format from now on.

 Thanks again