Re: [fltk.coredev] Evaluate hypothesis of using GDI+ for the Windows platform - [General Use] - Forums

On Wednesday, March 3, 2021 at 1:11:40 PM UTC+1 MacArthur, Ian (Leonardo, UK) wrote:

I ran through the tests and all looks pretty good. The lines and circles are smoothed (though the AA that GDI+ provides still looks a bit "disappointing" compared to what other more recent systems seem to achieve... i.e. compared to the Mac.)

Drawing quality is remarkable in macOS.

The text rendering now looks (and is?) basically the same as we had before, which is "better" than GDI+ could do, I think.

That is plain GDI code.

> The plastic and gleam schemes are completely GDI-based, so there's no slowdown
> when they are used.

Hmm, that's not what I find.
In my tests, the "gleam" scheme now appears to be (almost) as fast as stock. TBH I can not really tell, it may be exactly as fast, but I "feel" it is still slightly slower...

The "plastic" scheme is still slow.

My tests are with Windows 10 in Virtualbox on macOS. There, I don't see the plastic scheme slow.

Also, try this: If you are running "unittests", go to the schemes page and select the "plastic" scheme and then display "Tab 1" which has the two clocks on it.
Observe two things:
1 - the clock hands are smooth and AA
2 - every time the clocks tick the clock faces "jitter" as they are refreshed

I don't see any jitter.

Actually the "jitter" is present in all schemes, not just "plastic", but is most visible in "plastic." When the second-hand is at 3, 6, 9, 12 the clock face does not jitter, so presumably horizontal/vertical lines (non-GDI+) are fine...

The clock hands are always drawn with GDI+, whatever their position.

This is *something* to do with the single-window buffering I believe (as I think Greg reported earlier.)

To see this, run the "doublebuffer" test and position the two windows side-by side.
In the Fl_Single_Window, click at the left end of the slider - the window redraws with a single line.
Now click at the right end of the slider - you can actually see the lines redrawing (at least on this laptop, which is fairly high-end!)

Repeat on the Fl_Double_Window and the redraws are basically instant.

I'd say, the single-window progressive drawing is visible and takes a few tenths of a second,

whereas the double-buffered window drawing is delayed a fraction of a second after the click

and then nearly instantaneous.

This effect is visible regardless of selected scheme, so the underlying issue may be the window buffering - basically it would seem that GDI+ really only works for double_windows...

We may say that few FLTK window redraws can use as many antialiased oblique lines as with test/doublebuffer.exe,

so the time delay introduced by GDI+ should be hardly perceivable.

> Configure.ac checks for presence of GDI+ and doesn't compile GDI+-using code in its
> absence. Thus, the FLTK library remains compatible with Windows95.

Cool. Though - I have not tried that!

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.
********************************************************************