FLTK logo

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

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.general  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: Re: Can custom box type functions handle their own high-DPI screen scaling? Manolo Feb 25, 2021  
 

On Thursday, February 25, 2021 at 1:57:34 PM UTC+1 Albrecht Schlosser wrote:
On 2/25/21 11:16 AM Manolo wrote:
> There's now a new public API in FLTK 1.4 to support "drawing without
> scaling factor",
> in the form of a pair of functions that remove and then restore the
> scaling factor:
>    float fl_remove_scale();
>   void fl_restore_scale(float s);

Thanks, that's great. The "naive" implementation to reset the scale
didn't work well on my macOS system (I think you know why) but with the
new API it works fine.

Almost. See below.

May I request to change fl_remove_scale() to fl_reset_scale() ? "Remove"
sounds strange in this context.

> I attach the same example program modified to use this API.

Okay, works fine on Linux (not tested elsewhere). Your program doesn't
show any issues in my tests.

My own modified test program that demonstrates switching the scaling
factor back and forth after drawing the box and before drawing the label
fails in some situations. I attach my demo 'draw_unscaled.cxx' here. I
also attach 'draw_unscaled.png' which shows a failure situation.

If there's anything wrong with my test program, please tell me.
Yes. There is. That program assumes the font face and size are correctly set
when fl_text_extents() is called. But that's not the case at the very beginning
of the draw() method.

If you add
    fl_font(labelfont(), labelsize());
just before
    fl_text_extents(label(), dx, dy, ll, lh);
all runs smoothly.

My simpler version added custom code after Fl_Button::draw() which
does set the font face and size adequately.

Otherwise this seems to be a bug.

What I found out with my demo: it's somehow interfering with the
transient scaling factor display window when the scaling is changed
(ctrl/+ or ctrl/-). I see very similar effects on macOS with cmd/+ or
cmd/- but I didn't test on Windows.
The transient window display lets the font size to large values which produce
erroneously large colored boxes later.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/400dc698-4b98-4f78-889d-99ee0b3d4ffcn%40googlegroups.com.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.