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

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.

Indeed - it is very good - years ago I had a thing that was rendering the main scene with Cairo, but on the Mac it was easier just to draw with fltk, since the rendered view was easily as good (or better) and it was a whole lot faster.

(Cairo generally does a nice job, but it can be slow..)

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

I'm using Win10, on a laptop - it's a pretty decent laptop with a decent (for a laptop) GPU, and rendering is usually swift… But this is slow.

If I can remember what I did, I’ll try and capture another video that shows the effects I described.

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.

OK - on this laptop it is *very* perceivable!

I'll try and grab a video, if I can remember what I did before…

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