Vote about using antialiased lines and curves on the Windows platform

[Manolo]

Please vote about having the Windows FLTK platform draw oblique lines,

curves and all complex shapes in antialiased form. The result of this change is

visible in the attached snapshot where left elements show the current products

and right elements show the effect of the proposed changes, both under Windows 10.

The code for that is in branch GDI+soft of https://github.com/ManoloFLTK/fltk

That code uses GDI+ only when it improves the quality of current drawings,

that is, when drawing non horizontal nor vertical lines or when drawing curves.
All the rest (e.g., text, images, horizontal and vertical lines, rectangles) are

processed unchanged by GDI.

As Ian has reported, drawing with GDI+ is slightly slower than with GDI. This is visible

with the test/doublebuffer program which takes a short but perceivable time

to complete redrawing with its highest number of oblique lines that are drawn with GDI+

in the new code. Notice that line #37 of test/doublebuffer.cxx reads :

    // this purposely draws each line 10 times to be slow:

Therefore, It takes an unrealistic number of GDI+ operations for the slowing to be visible.

GDI+ is supported from Windows XP and up. When GDI+ isn't available, the modified

code falls back to GDI. Thus FLTK remains compatible with Windows 95.

Both configure-based and CMake-based builds are taken care of.

My vote is +1

TIA - Manolo

[Bill Spitzak]

Despite the same less-than-steller performance, the X11 version should also be changed to Cairo, unless somebody has a better idea about how to make antialiased lines. Cairo version needs some messing with to produce "hinting" which is basically to move lines and shapes so they don't produce unwanted blur, Cairo by itself is very insistent on exact reproduction of the filtered image.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/b1228649-ecc4-4ef0-bbd7-e47932214b86n%40googlegroups.com.

[Gonzalo Garramuño]

El 17/5/21 a las 12:39, Bill Spitzak escribió:

Despite the same less-than-steller performance, the X11 version should also be changed to Cairo, unless somebody has a better idea about how to make antialiased lines. Cairo version needs some messing with to produce "hinting" which is basically to move lines and shapes so they don't produce unwanted blur, Cairo by itself is very insistent on exact reproduction of the filtered image.

On Mon, May 17, 2021 at 12:54 AM Manolo <manol...@gmail.com> wrote:

Please vote about having the Windows FLTK platform draw oblique lines,

curves and all complex shapes in antialiased form.

As Ian has reported, drawing with GDI+ is slightly slower than with GDI.

GDI+ is supported from Windows XP and up. When GDI+ isn't available, the modified

code falls back to GDI. Thus FLTK remains compatible with Windows 95.

Both configure-based and CMake-based builds are taken care of.

My vote is +1

TIA - Manolo

--

My vote is +1 for an OPT IN option in cmake/configure.  And -1 for a default option.  Both for GDI+ and Cairo.  In both cases the performance of my program would suffer otherwise.

[Ian MacArthur]

I’m greatly in favour of anti-aliased rendering, and I do not want to be negative about the great work Manolo has done in getting it to run inside fltk, but I’m not at all convinced by GDI+.
As Manolo said, I have hit issues with it being *slow*.
Now, others tried testing when I reported slowness, and didn’t see the effect I was seeing, and Manolo reports it is “slightly slower” than GDI for him. (And others report no noticeable slowness under Vbox, for example...)
But for me *on some machines* it can be very slow - whereas the same code on another machine seems fine.
I assume it is some display-driver related issue though I have no clue what.
For me, one of the “slow” machines is my good HP laptop, which is pretty decent spec., Nvidia GPU etc. and generally swift (by laptop standards) but chokes sometimes on the GDI+ tests I did.
It also seems to matter if the window is double buffered or not (Fl_Double_Window seems not to choke quite as badly...)

So for me, I would not vote to make GDI+ the default, though it could be a compile time option, as Gonzalo suggested.

As far as I can make out, MS have pretty much given up on GDI+ themselves; GDI has evolved such that it now has some hardware acceleration on most machines, but GDI+ is always soft rendered.

The MS anointed approach now is to use Direct2D apparently, which is h/w accelerated - but only supported on Vista and later (which is when they gave up on GDI+ dev, I think.)

So *if* we have this, I’d prefer it were optional, and if it were optional then possibly Direct2D rather than GDI+.
But since it seems very unlikely I’ll put in the work necessary to make that happen, that probably doesn’t count for much!

To some extent, I feel the same about Cairo (as Bill suggested) - again it is soft rendered, and in the past I was hit pretty badly by it being unusably slow, so now I am wary of using it much. Of course, it may have improved in the meantime, but... Perhaps it is fine for the simple 2D geometry that most widgets use; I don’t know...

If all windows were GL windows, could we just render “everything” via GL and get h/w accelerated rendering pretty much on all hosts that way?

[Gonzalo Garramuño]

El 17/05/2021 a las 04:54, Manolo escribió:
> The code for that is in branch GDI+soft of
> https://github.com/ManoloFLTK/fltk
>
> That code uses GDI+ only when it improves the quality of current drawings,
> that is, when drawing non horizontal nor vertical lines or when
> drawing curves.
> All the rest (e.g., text, images, horizontal and vertical lines,
> rectangles) are
> processed unchanged by GDI.

> GDI+ is supported from Windows XP and up. When GDI+ isn't available,
> the modified
> code falls back to GDI. Thus FLTK remains compatible with Windows 95.
>
> Both configure-based and CMake-based builds are taken care of.
>
> My vote is +1
>
> TIA - Manolo

I tried it with cmake build and tried it on my viewer to really measure
how much of a performance hit I would get.

I had to link my program with GDIplus.lib.  The result, however, was
that my viewer crashed on startup with an unknown exception being thrown.

So, my vote has to be -1 for now.

--
Gonzalo Garramuño

[Lauri Kasanen]

On Mon, 17 May 2021 13:10:59 -0300
Gonzalo Garramuño wrote:

> My vote is +1 for an OPT IN option in cmake/configure.  And -1 for a
> default option.  Both for GDI+ and Cairo.  In both cases the performance
> of my program would suffer otherwise.

Cairo is a big dep, so my vote is it should be optional.

GDI+ I have no opinion on, I don't use Windows.

- Lauri

[Manolo]

On Monday, May 17, 2021 at 6:11:03 PM UTC+2 ggar...@gmail.com wrote:

My vote is +1 for an OPT IN option in cmake/configure.  And -1 for a default option.  Both for GDI+ and Cairo.  In both cases the performance of my program would suffer otherwise.

@Gonzalo: could you, please, detail why you expect your app to "suffer" from the proposed change?

I'd like to stress that only circles, arcs and oblique lines would be drawn with GDI+.

[Manolo]

On Monday, May 17, 2021 at 10:26:47 PM UTC+2 imacarthur wrote:

I’m greatly in favour of anti-aliased rendering, and I do not want to be negative about the great work Manolo has done in getting it to run inside fltk, but I’m not at all convinced by GDI+.
As Manolo said, I have hit issues with it being *slow*.
Now, others tried testing when I reported slowness, and didn’t see the effect I was seeing, and Manolo reports it is “slightly slower” than GDI for him. (And others report no noticeable slowness under Vbox, for example...)
But for me *on some machines* it can be very slow - whereas the same code on another machine seems fine.
I assume it is some display-driver related issue though I have no clue what.
For me, one of the “slow” machines is my good HP laptop, which is pretty decent spec., Nvidia GPU etc. and generally swift (by laptop standards) but chokes sometimes on the GDI+ tests I did.

@Ian: I would like to be sure you measure the current proposal is meant to account for the findings you have reported.

With it, GDI+ would be used only to draw circles, arcs and oblique lines, so that the vast majority of FLTK drawings

are unchanged. I also stress the test/doublebuffer program is very artificial in that each line gets drawn 10 times.

 

If all windows were GL windows, could we just render “everything” via GL and get h/w accelerated rendering pretty much on all hosts that way?

That would be achievable completing the implementaton of the Fl_OpenGL_Graphics_Driver class  which is now only sketched.

[Manolo]

On Tuesday, May 18, 2021 at 2:50:45 AM UTC+2 ggar...@gmail.com wrote:

I tried it with cmake build and tried it on my viewer to really measure
how much of a performance hit I would get.

Thanks. That would be very helpful.

I had to link my program with GDIplus.lib.  The result, however, was
that my viewer crashed on startup with an unknown exception being thrown.

All demo programs do build with CMake and run. A detail of where the crash appears

in your app would be helpful.

[Greg Ercolano]

On 5/17/21 12:54 AM, Manolo wrote:

That code uses GDI+ only when it improves the quality of current drawings,

that is, when drawing non horizontal nor vertical lines or when drawing curves.
All the rest (e.g., text, images, horizontal and vertical lines, rectangles) are

processed unchanged by GDI.

[..]

GDI+ is supported from Windows XP and up. When GDI+ isn't available, the modified

code falls back to GDI. Thus FLTK remains compatible with Windows 95.

Both configure-based and CMake-based builds are taken care of.

My vote is +1

    Regarding GDI, I'm undecided (+0/-0) as I've not tested for slowness
    with the latest incarnation, but perhaps that'd be a good default since
    GDI is part of the OS (assuming it's not slow). Just be sure there's a flag
    to disable it, as some might run into trouble with GDI and want to turn it off.

    I think Bill brought up cairo on X11, which may have tainted some other folk's
    votes after that; everyone who voted with cairo in mind should be aware Manolo's
    OP never mentioned cairo.

    Regarding cairo, I'd be a big -1 for cairo being on by default (if cairo is present),
    as I have cairo installed just for testing, but I definitely don't ever want it  to be on
    "by default", as it's definitely slow and heavy. Some systems  may come with cairo
    pre-installed, so a default cairo on would automatically involve cairo if it were default.
    IMHO cairo should never be the default. But if you want, cmake could print a note
    in a highlight color indicating "Cairo found but not enabled. (If you want antialiasing
    in FLTK, you can enable cairo with -xxx)"

[Gonzalo Garramuño]

The crash happens after my program changes in its preferences the color of all the palette with Fl::set_color( id, Fl_Color ) to a dark scheme.

-- 
Gonzalo Garramuño

[Manolo]

On Tuesday, May 18, 2021 at 6:24:03 PM UTC+2 er...@seriss.com wrote:

    Regarding GDI, I'm undecided (+0/-0) as I've not tested for slowness
    with the latest incarnation, but perhaps that'd be a good default since
    GDI is part of the OS (assuming it's not slow). Just be sure there's a flag
    to disable it, as some might run into trouble with GDI and want to turn it off.

@Greg: I take GDI should be replaced by GDI+ in all of the above paragraph. Is that correct?

Yes, configure --disable-gdiplus would fall back to 100% GDI drawing, as currently in FLTK.

And similarly under CMake.

[Greg Ercolano]

On 5/18/21 10:02 AM, Manolo wrote:

On Tuesday, May 18, 2021 at 6:24:03 PM UTC+2 er...@seriss.com wrote:

    Regarding GDI, I'm undecided (+0/-0) as I've not tested for slowness
    with the latest incarnation, but perhaps that'd be a good default since
    GDI is part of the OS (assuming it's not slow). Just be sure there's a flag
    to disable it, as some might run into trouble with GDI and want to turn it off.

@Greg: I take GDI should be replaced by GDI+ in all of the above paragraph. Is that correct?

    Oh, yes indeed.

Yes, configure --disable-gdiplus would fall back to 100% GDI drawing, as currently in FLTK.

And similarly under CMake.

    Right, that sounds good.
    I'm still undecided about the default.

    Perhaps I'd be +1 for making it default /just/ during the pre-1.4.0 testing phase,
    so we can explore if there are any problems, and when we actually release 1.4.0,
    we can decide if it should be left on or not.

    This way it will really get tested, which is perhaps what your goal is for making it
    a default, at least during the ramp up to the 1.4.0 release to see if it tests well.

[Ian MacArthur]

On 18 May 2021, at 08:40, Manolo wrote:
>
> @Ian: I would like to be sure you measure the current proposal is meant to account for the findings you have reported.
> With it, GDI+ would be used only to draw circles, arcs and oblique lines, so that the vast majority of FLTK drawings
> are unchanged. I also stress the test/doublebuffer program is very artificial in that each line gets drawn 10 times.

OK - first off, I don't want to cause any upset, and I know you have done a huge amount of work to get the GDI+ working as well as it does, but I have to say I’m really not keen on it, and would be very uncomfortable about it being made the *default* build choice. I’m fine with it being a choice.

It does affect my build quite badly, in some cases and/or on some machines, and in any case it “feels” a bit more sluggish to me, on all my tests.

I can’t post my actual code, and I acknowledge that test/doublebuffer is unrepresentative (though it does show the effect quite well[1]) but here’s an simple test we can all try at home.

On a Windows build of the GDI+ branch, run the test/unittests program and resize it to a large window, then select the “schemes test” tab, and there select the “plastic” theme (plastic because it seems, for me at least, to be the worst case...)

Now click on the lower right corner and start dragging the window corner about to resize it - it will redraw as it resizes.
Well, with the “plain” GDI build it redraws for me pretty much as fast as I move the mouse.
With the GDI+ build it really does not - it updates sporadically and is always a way behind where the mouse pointer has got to.

Again, this is a somewhat artificial test, but I think it shows the speed difference in quite a clear way. I do not know what others will see when they try this on their machines though... indeed I’d be interested to hear!

>
> If all windows were GL windows, could we just render “everything” via GL and get h/w accelerated rendering pretty much on all hosts that way?
> That would be achievable completing the implementaton of the Fl_OpenGL_Graphics_Driver class which is now only sketched.

Hmm. OK.
I doubt I have the skills to make that work but a version that used a GL or EGL backend for all rendering might be a “one size fits all” solution across multiple platforms (including Android?)
I do not know, though.



[1] - I tried to screen cap a video of test/doublebuffer on my HP laptop, and the video doesn’t really show the effect; it doesn’t look like what was on the screen at the time. This, in itself, might be a clue as to what’s going on. I’m guessing it is something to do with the drawing blocking on frame-synch to prevent tearing or something, and that might also explain why double-buffered windows exhibit the effect significantly less.

[Gonzalo Garramuño]

El 18/05/2021 a las 04:57, Manolo escribió:

I found out the crash appears in my application even when GDIplus is off.  So something has changed in the fltk internals in the Manolo/fltk repository.

-- 
Gonzalo Garramuño

[Gonzalo Garramuño]

El 18/05/2021 a las 18:05, Ian MacArthur escribió:
> On a Windows build of the GDI+ branch, run the test/unittests program and resize it to a large window, then select the “schemes test” tab, and there select the “plastic” theme (plastic because it seems, for me at least, to be the worst case...)
>

> Again, this is a somewhat artificial test, but I think it shows the speed difference in quite a clear way. I do not know what others will see when they try this on their machines though... indeed I’d be interested to hear!

Funny enough, I tried the same test (cause I was trying to reproduce the
change in scheme and color theme) with the same settings as you and
found the same abismal performance.  So I second that I wouldn't like
GDIplus to be the default option on Windows.

--
Gonzalo Garramuño

[Manolo]

On Tuesday, May 18, 2021 at 6:55:29 PM UTC+2 ggar...@gmail.com wrote:

The crash happens after my program changes in its preferences the color of all the palette with Fl::set_color( id, Fl_Color ) to a dark scheme.

It's difficult to fix for sure without more detail, but, please, pull from the git repository and try again. It's hopefully fixed.

[Gonzalo Garramuño]

El 19/5/21 a las 06:42, Manolo escribió:

On Tuesday, May 18, 2021 at 6:55:29 PM UTC+2 ggar...@gmail.com wrote:

The crash happens after my program changes in its preferences the color of all the palette with Fl::set_color( id, Fl_Color ) to a dark scheme.

It's difficult to fix for sure without more detail, but, please, pull from the git repository and try again. It's hopefully fixed.

I managed to fix it on my end.  The problem was some old include files with the new lib files and cmake picking the wrong includes.  Sorry for the trouble.

[Albrecht Schlosser]

On 5/17/21 9:54 AM Manolo wrote:

Please vote about having the Windows FLTK platform draw oblique lines,

curves and all complex shapes in antialiased form. The result of this change is

visible in the attached snapshot where left elements show the current products

and right elements show the effect of the proposed changes, both under Windows 10.

The code for that is in branch GDI+soft of https://github.com/ManoloFLTK/fltk

Sorry for the late reply, I've been too busy to test. I read all comments so far and I'll try to get to testing later today.

I can test the performance issues in a Virtualbox VM and, if necessary, on the same (dual boot) machine in a native Windows boot.

For now I have just a thought and a question. Ian wrote in one of his replies:

So *if* we have this, I’d prefer it were optional, and if it were optional then possibly Direct2D rather than GDI+.

Manolo, could you imagine to do the same (line drawing only) work with Direct2D as Ian suggested? I'm asking this because you're the one who knows all that driver stuff best, and now that you have done it with GDI+, can you estimate the effort necessary to do this?

Please don't understand me wrong, it's just a thought. Since MS seems to have given up on GDI+, wouldn't it be a step backwards if we introduced GDI+ now? Maybe MS will drop support in a future version or ... (who knows?).

Well, while I'm writing this, another question came up: IIRC the gleam scheme draws the color gradients as adjacent horizontal lines. Wouldn't this be affected by the performance penalty as well?

[Manolo]

On Wednesday, May 19, 2021 at 1:34:10 PM UTC+2 Albrecht Schlosser wrote:

Manolo, could you imagine to do the same (line drawing only) work with Direct2D as Ian suggested? I'm asking this because you're the one who knows all that driver stuff best, and now that you have done it with GDI+, can you estimate the effort necessary to do this?

No way. I don't know Direct2D and don't want to invest time in this MS-only API.

Please don't understand me wrong, it's just a thought. Since MS seems to have given up on GDI+, wouldn't it be a step backwards if we introduced GDI+ now? Maybe MS will drop support in a future version or ... (who knows?).

MS has been maintaining back compatibility very seriously for many years. The exact opposite of what Apple does.

Well, while I'm writing this, another question came up: IIRC the gleam scheme draws the color gradients as adjacent horizontal lines. Wouldn't this be affected by the performance penalty as well?

The fact that only oblique lines and curves are drawn with GDI+ in my proposal, doesn't seem to make its way.

[Lauri Kasanen]

On Wed, 19 May 2021 05:03:23 -0700 (PDT)
Manolo wrote:

> The fact that only oblique lines and curves are drawn with GDI+ in my
> proposal, doesn't seem to make its way.

Nobody knows what "oblique" means. I speak perfect English as a second
language and even I would need to google it. How about "angled"?

- Lauri

[Gonzalo Garramuño]

El 18/05/2021 a las 04:57, Manolo escribió:

On Tuesday, May 18, 2021 at 2:50:45 AM UTC+2 ggar...@gmail.com wrote:

I tried it with cmake build and tried it on my viewer to really measure
how much of a performance hit I would get.

Thanks. That would be very helpful.

Ok.  I was able to test it with my viewer.  I did not notice any slowdowns except for the vectorscope which draws a lot of points (lines) in all directions.  In that case the slowdown was from 5 iterations of the vectorscope down to only 3 iterations during playback.  Also, I did not see much improvement in any of my widgets' antialias except for some round buttons.

I wonder... is there any way to draw aliased lines when gdi is on?  That is, temporarily turn it off, so that I draw all my vectorscope lines fast while the vectorscope markings are drawn antialiased.

Other than that, in my case, the pros are not enough to have it turned on by default.

-- 
Gonzalo Garramuño

[imacarthur]

On Wednesday, 19 May 2021 at 12:34:10 UTC+1 Albrecht Schlosser wrote:

Manolo, could you imagine to do the same (line drawing only) work with Direct2D as Ian suggested? I'm asking this because you're the one who knows all that driver stuff best, and now that you have done it with GDI+, can you estimate the effort necessary to do this?

Hmm, I suspect that's an awful lot of work for anyone to undertake.

I know I've been thinking about it, but I keep putting it off because it is too much...

Also, Direct2D is limiting in terms of backwards compatibility; you need at least Vista, whereas GDI+ goes a long way back!

 

Well, while I'm writing this, another question came up: IIRC the gleam scheme draws the color gradients as adjacent horizontal lines. Wouldn't this be affected by the performance penalty as well?

I had that thought, but I do not think it can be so - the gradient is largely horizontal lines, so should not trigger the GDI+ code paths here?

 

[imacarthur]

Nobody knows what "oblique" means. I speak perfect English as a second
language and even I would need to google it. How about "angled"?

Hi Lauri,

I knew what oblique meant!

And it is the "correct" word in that context.

But I concede that "angled" carries the same meaning here and may be more widely understood.

 

[imacarthur]

Ok.  I was able to test it with my viewer.  I did not notice any slowdowns except for the vectorscope which draws a lot of points (lines) in all directions.  In that case the slowdown was from 5 iterations of the vectorscope down to only 3 iterations during playback.  Also, I did not see much improvement in any of my widgets' antialias except for some round buttons.

Is your vectorscope refresh dominated entirely by the rendering, or is it computationally bounded too?

If it is just the rendering time that dominates, it might be worth trying to see if GL would draw it quicker (since the GL path is likely to be using the 3D hardware accel. in the GPU and hence could be "much" faster.) Well, at least on machines with GL support in the hardware of course, though that is pretty commonplace these days.

But it is a lot of work to port the drawing, though...

[Gonzalo Garramuño]

Yes, I should be drawing it with GL.  It is much faster. I am now porting the code.

-- 
Gonzalo Garramuño

[Albrecht Schlosser]

On 5/19/21 1:34 PM Albrecht Schlosser wrote:
> On 5/17/21 9:54 AM Manolo wrote:
>>
>> Please vote about having the Windows FLTK platform draw oblique lines,
>> curves and all complex shapes in antialiased form. The result of this
>> change is
>> visible in the attached snapshot where left elements show the current
>> products
>> and right elements show the effect of the proposed changes, both
>> under Windows 10.
>>
>> The code for that is in branch GDI+soft of
>> https://github.com/ManoloFLTK/fltk
>

> I can test the performance issues in a Virtualbox VM and, if
> necessary, on the same (dual boot) machine in a native Windows boot.

I tested on both the VM and the bare-metal Win10 system and I can
confirm severe performance issues with the new 'gdi+soft' branch.
Anti-aliased line drawing comes with a price.

However, I believe that there may be many applications that don't suffer
from this performance penalty and thus my vote is

+1 on integration of the new 'gdi+soft' branch

Should 'gdi+' be the default?

I'm not sure, but I suggest to make it the default for 1.4.x development
so it can easily be tested and will be the default in snapshots that
users may test. I agree with Greg (IIRC) that this will be a good way to
get feedback from users.

Depending on the feedback (or no feedback) we may reconsider the default
(GDI or GDI+) before we release FLTK 1.4.

I'd also like to see an option to switch drivers (GDI <-> GDI+)
dynamically so users can maybe switch back to pure old GDI in
time-critical drawing paths (somebody mentioned this, IIRC). This option
might already exist (internally) but I don't know if there's an API to
be easily applied. If so, it should be documented.

Last but not least: Many thanks to Manolo for developing this great
improvement!

[Albrecht Schlosser]

On 5/19/21 2:03 PM Manolo wrote:

On Wednesday, May 19, 2021 at 1:34:10 PM UTC+2 Albrecht Schlosser wrote:

Manolo, could you imagine to do the same (line drawing only) work with Direct2D as Ian suggested? I'm asking this because you're the one who knows all that driver stuff best, and now that you have done it with GDI+, can you estimate the effort necessary to do this?

No way. I don't know Direct2D and don't want to invest time in this MS-only API.

I understand that. Thanks for your ongoing work on improving FLTK!

Please don't understand me wrong, it's just a thought. Since MS seems to have given up on GDI+, wouldn't it be a step backwards if we introduced GDI+ now? Maybe MS will drop support in a future version or ... (who knows?).

MS has been maintaining back compatibility very seriously for many years. The exact opposite of what Apple does.

Indeed.

Side note, FTR:

The new code implements "only some GDI+ drawing methods" on top of the GDI driver which manifests in the following diffs (not taking into account the minor and straight-forward build system related changes):

$ git status
On branch GDI+soft_rebased
$ git diff --stat master -- src/Fl_win32.cxx src/drivers/
 src/Fl_win32.cxx                                      |   3 +
 src/drivers/GDI/Fl_GDI_Copy_Surface_Driver.cxx        |   4 +-
 src/drivers/GDI/Fl_GDI_Graphics_Driver.H              |  44 ++++++++++
 src/drivers/GDI/Fl_GDI_Graphics_Driver.cxx            |  33 ++++++++
 src/drivers/GDI/Fl_GDI_Graphics_Driver_arci.cxx       |  24 ++++++
 src/drivers/GDI/Fl_GDI_Graphics_Driver_color.cxx      |  12 +++
 src/drivers/GDI/Fl_GDI_Graphics_Driver_font.cxx       |   2 +
 src/drivers/GDI/Fl_GDI_Graphics_Driver_line_style.cxx |  48 +++++++++++
 src/drivers/GDI/Fl_GDI_Graphics_Driver_rect.cxx       |  86 +++++++++++++++++++
 src/drivers/GDI/Fl_GDI_Graphics_Driver_vertex.cxx     | 123 ++++++++++++++++++++++++++++
 src/drivers/GDI/Fl_GDI_Image_Surface_Driver.cxx       |   2 +-
 11 files changed, 378 insertions(+), 3 deletions(-)


I assume the same driver methods could be implemented using Direct2D in the future if this turns out to be doable by someone knowing this API and willing to do it. That is, if we can combine Direct2D with GDI in the same way it is done now with GDI and GDI+.

The backwards compatibility issue (Direct2D not available prior to Windows Vista) shouldn't be a problem because this would be an improvement that's just not available to older systems.

[Manolo]

On Friday, May 21, 2021 at 2:11:12 PM UTC+2 Albrecht Schlosser wrote:

I tested on both the VM and the bare-metal Win10 system and I can
confirm severe performance issues with the new 'gdi+soft' branch.
Anti-aliased line drawing comes with a price.

However, I believe that there may be many applications that don't suffer
from this performance penalty and thus my vote is

+1 on integration of the new 'gdi+soft' branch

Should 'gdi+' be the default?

I'm not sure, but I suggest to make it the default for 1.4.x development
so it can easily be tested and will be the default in snapshots that
users may test. I agree with Greg (IIRC) that this will be a good way to
get feedback from users.

Yes, that's a good suggestion.

Depending on the feedback (or no feedback) we may reconsider the default
(GDI or GDI+) before we release FLTK 1.4.

I'd also like to see an option to switch drivers (GDI <-> GDI+)
dynamically so users can maybe switch back to pure old GDI in
time-critical drawing paths (somebody mentioned this, IIRC). This option
might already exist (internally) but I don't know if there's an API to
be easily applied. If so, it should be documented.

Very well.
I'll try to support dynamic set/unset of antialiasing and will ask for a new vote with it.

[Ian MacArthur]

On 21 May 2021, at 13:11, Albrecht Schlosser wrote:
>
> I'd also like to see an option to switch drivers (GDI <-> GDI+) dynamically so users can maybe switch back to pure old GDI in time-critical drawing paths (somebody mentioned this, IIRC). This option might already exist (internally) but I don't know if there's an API to be easily applied. If so, it should be documented.

I have no idea if this is even feasible?
We’ve never really had support for changing the back-end dynamically at runtime, though, have we? It’s always been a build-time sort of option.

Changing the rendering mechanism dynamically at runtime might be quite cool though (not just for this, but in general) but it sounds like quite a challenge.

> Last but not least: Many thanks to Manolo for developing this great improvement!

Indeed; it’s a huge piece of work...

[Albrecht Schlosser]

On 5/21/21 9:57 PM Ian MacArthur wrote:
> On 21 May 2021, at 13:11, Albrecht Schlosser wrote:
>> I'd also like to see an option to switch drivers (GDI <-> GDI+) dynamically so users can maybe switch back to pure old GDI in time-critical drawing paths (somebody mentioned this, IIRC). This option might already exist (internally) but I don't know if there's an API to be easily applied. If so, it should be documented.
> I have no idea if this is even feasible?
> We’ve never really had support for changing the back-end dynamically at runtime, though, have we? It’s always been a build-time sort of option.

Changing the "driver" during runtime is well-established. Think of
offline drawing, Fl_Printer, and whatnot.

> Changing the rendering mechanism dynamically at runtime might be quite cool though (not just for this, but in general) but it sounds like quite a challenge.

The difference here would be that we change the drawing context, not the
device per se (i.e. we're still drawing to the display). This might
indeed be more involved, but Manolo said already that he would try it.
Looking forward to his results.

[Ian MacArthur]

On 21 May 2021, at 22:12, Albrecht Schlosser wrote:
>
> On 5/21/21 9:57 PM Ian MacArthur wrote:
>> On 21 May 2021, at 13:11, Albrecht Schlosser wrote:
>>> I'd also like to see an option to switch drivers (GDI <-> GDI+) dynamically so users can maybe switch back to pure old GDI in time-critical drawing paths (somebody mentioned this, IIRC). This option might already exist (internally) but I don't know if there's an API to be easily applied. If so, it should be documented.
>> I have no idea if this is even feasible?
>> We’ve never really had support for changing the back-end dynamically at runtime, though, have we? It’s always been a build-time sort of option.
>
> Changing the "driver" during runtime is well-established. Think of offline drawing, Fl_Printer, and whatnot.

OK, yes, this is true. I think I expressed myself poorly here... in essence, I think that GDI and GDI+ are “the same” driver, but have somewhat different internal paths for the rendering. It is this internal path that we would have to change dynamically, and I do not think that is a thing we do at present, changing the internals of the driver to use a different back-end during runtime...?

[Albrecht Schlosser]

The GDI and GDI+ drivers are different classes. The GDI+ driver is
derived from the GDI driver and defines its own virtual methods. IMHO
the only part we don't have yet is that at initialization time only one
of these two drivers is instantiated which is done by #ifdef'ed code. If
we managed to instantiate both drivers and assign the "correct one" at
any time we can presumably switch drivers as we like. Another problem I
can see may be the driver's (i.e. GDI vs. GDI+) internal Windows context
but I don't know anything about that.

Note that this view is partially backed by viewing the current source
code (virtual driver methods) but other parts are just educated guesses
and may be oversimplified.