RE: [fltk.general] Re: Can custom box type functions handle their own high-DPI screen scaling? - [General Use]

[MacArthur, Ian (Leonardo, UK)]

> I'm  satisfied by neither proposal.
>
> What about
> fl_undo_scale() / fl_redo_scale()
> or
> fl_scale_undo() / fl_scale_redo()
>
> Please read "Could Greg or Ian help us?"

Hah! I'd caution that just because the vocabulary seems similar, that does not mean it's the same language! :-)

FWIW, I don’t think there's a "best" name for this, so we'd have to describe the behaviour in the docs anyway!

I quite fancy:

fl_override_scale() paired with fl_restore_scale()

Just to add extra confusion to the discussion.
What I'm trying to *imply* (with these names) it that this is a "temporary" change of the display scale, if you see what I mean...


Leonardo MW Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Greg Ercolano]

On 2/25/21 7:30 AM, 'MacArthur, Ian (Leonardo, UK)' via fltk.general wrote:

I'm  satisfied by neither proposal.

What about
fl_undo_scale() / fl_redo_scale()
or
fl_scale_undo() / fl_scale_redo()

Please read "Could Greg or Ian help us?" 

Hah! I'd caution that just because the vocabulary seems similar, that does not mean it's the same language!   :-)
FWIW, I don’t think there's a "best" name for this, so we'd have to describe the behaviour in the docs anyway!

I quite fancy:

	fl_override_scale()  paired with  fl_restore_scale()

Just to add extra confusion to the discussion.

    Throwing my hat in the ring:

        fl_unscale() / fl_rescale()

    ..or if there's a stack:

        fl_push_scale() / fl_pop_scale()

[MacArthur, Ian (Leonardo, UK)]

I quite fancy:

  fl_override_scale()  paired with  fl_restore_scale()

Just to add extra confusion to the discussion.

    Throwing my hat in the ring:

        fl_unscale() / fl_rescale()

    ..or if there's a stack:

        fl_push_scale() / fl_pop_scale()

 

I think we were meant to narrow the field down - instead we just seem to have made it worse!

Sorry….

 

 

 

[Albrecht Schlosser]

[I proposed:]

float fl_reset_scale(); / void fl_restore_scale(float s);

[Manolo wrote:]

>>> What about
>>> fl_undo_scale() / fl_redo_scale()
>>> or
>>> fl_scale_undo() / fl_scale_redo()
>>>

[Ian wrote:]

>> I quite fancy:
>>
>> fl_override_scale() paired with fl_restore_scale()
>>
>> Just to add extra confusion to the discussion.

[Greg wrote:]

>     Throwing my hat in the ring:
>
> fl_unscale() / fl_rescale()
>
>     ..or if there's a stack:
>
> fl_push_scale() / fl_pop_scale()

The latter would be my favorite *if* we had a stack, in analogy to
fl_push_clip() and fl_pop_clip() which appears related - and indeed it
is somehow because you can't change scaling w/o taking care of clipping.

So this would be (with types and parameters):

float fl_push_scale(float s); / void fl_pop_scale();

The former would return the previous scale value (or void would also be
OK). The latter *could* return the /new/ scale value but void would be fine.

Unless we go the push/pop route with stack I'd favor Ian's
fl_override_scale() or my proposal fl_reset_scale().

Or, what about this?

float fl_set_scale(float s); // returns old value
void fl_restore_scale(float s); // as we have now

[Greg Ercolano]

On 2/25/21 9:59 AM, Albrecht Schlosser wrote:

Or, what about this?

  float fl_set_scale(float s);    // returns old value
  void fl_restore_scale(float s); // as we have now

    I do like the 'save' and 'restore' wording in a non-stack situation.

[Bill Spitzak]

I think the existing fl_push_matrix and fl_pop_matrix should be reused.

However the idea of fl_set_scale(x), returning the old value, is probably good. The result is that the determinant of the matrix is x. I am unsure exactly what this should do to existing translation, rotation, and non-equal scaling (including mirror reflections which might mean the determinant is -x).

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/d85fde75-504a-57cd-4fa7-0001aebe7af0%40seriss.com.

[Manolo]

I'm completely lost after all these propositions.

1) Functions fl_push_matrix()/fl_pop_matrix() belong to the "Drawing complex shapes" API

so they affect only that part of the drawing API. In contrast, the scaling factor affects all

drawing functions. I don't see how a transient change of the scaling factor

could be related to the transformation matrix of the "complex shapes" API.

2) Proposal for this function

   float fl_set_scale(float s);

involves two scaling factor values, the current one, and the new one, whereas in what has been

programmed, the new value is always 1. I don't see how changing the scaling factor to another

value makes sense. The goal is to allow working at the single pixel level. And only one

value of the scaling factor is compatible with that, value 1.f.

[Albrecht Schlosser]

On 2/26/21 9:42 AM Manolo wrote:
> I'm completely lost after all these propositions.
>
> 1) Functions fl_push_matrix()/fl_pop_matrix() belong to the "Drawing
> complex shapes" API
> so they affect only that part of the drawing API. In contrast, the
> scaling factor affects all
> drawing functions. I don't see how a transient change of the scaling factor
> could be related to the transformation matrix of the "complex shapes" API.

I agree, using the transformation would be bad and confusing (IMHO).

I believe we might need a warning in the docs that the transformation
matrix would need to be reset by the user if it's unity because of
different coordinate systems before and after resetting the scaling
factor. Otherwise the result of drawing complex shapes might be undefined.

> 2) Proposal for this function
>    float fl_set_scale(float s);
> involves two scaling factor values, the current one, and the new one,
> whereas in what has been programmed, the new value is always 1.
> I don't see how changing the scaling factor to another
> value makes sense. The goal is to allow working at the single
> pixel level. And only one value of the scaling factor is
> compatible with that, value 1.f.

Yes, you're right. I withdraw this proposal. The reason for using the
parameter "float s" was because "set_scale" should "set something". It
looked weird without an argument. Withdrawn.

My vote is now for Ian's

fl_override_scale() paired with fl_restore_scale()

followed by Greg's

fl_unscale() / fl_rescale()

or (yet another proposal)

fl_unset_scale() / fl_restore_scale()

[Manolo]

On Friday, February 26, 2021 at 10:27:03 AM UTC+1 Albrecht Schlosser wrote:

My vote is now for Ian's

fl_override_scale() paired with fl_restore_scale()

Good. That is also my favorite wording.

[Albrecht Schlosser]

On 2/26/21 10:47 AM Manolo wrote:

> On Friday, February 26, 2021 at 10:27:03 AM UTC+1 Albrecht Schlosser wrote:
>
> My vote is now for Ian's
>
> fl_override_scale() paired with fl_restore_scale()
>
> Good. That is also my favorite wording.

Great. Counting votes...

Ian (suggested it): likely +1
Manolo : +1
Albrecht : +1

Sounds like we got a winner ;-)

Greg?

[MacArthur, Ian (Leonardo, UK)]

> > My vote is now for Ian's
> >
> > fl_override_scale() paired with fl_restore_scale()
> >
> > Good. That is also my favorite wording.
>
> Great. Counting votes...
>
> Ian (suggested it): likely +1

Yes, I'm +1 on that name (unsurprisingly!)

> Manolo : +1
> Albrecht : +1
>
> Sounds like we got a winner ;-)
>
> Greg?

[Bill Spitzak]

You are right, I was thinking about the rewrite in fltk2 where all the drawing obeyed the current matrix.

From more recent experience, having the drawing library maintain a transform is not really useful and produces overhead and problems such as the current one where the code needs to know the transform to draw correctly. So it is probably good that the majority of the drawing functions do not use it.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/f359d90afb3747b29fbcb64761aa1678%40leonardocompany.com.