New vote about using antialiased lines and curves on the Windows platform

[Manolo]

The branch GDI+soft of https://github.com/ManoloFLTK/fltk

has been expanded to allow to turn on or off anti-aliasing when

drawing lines and curves on the Windows platform. The API for that is

-    void fl_antialias(int state);   <---- to turn antialiasing on or off

-    int  fl_antialias();    <----- to get the current state of antialiased drawing

Only the Windows platform (with the GDI+ option which is ON by default)

allows to turn antialiasing on or off.

The macOS platform is always on.

The X11 platform is always off.

Again, only oblique lines and curves are drawn with GDI+, unless

fl_antialias(0) has been called before. All the rest (rectangles,

horizontal and vertical lines, text, images) remains drawn with GDI.

Please, give again your vote about committing these changes to FLTK 1.4

TIA

[Gonzalo Garramuño]

El 27/5/21 a las 07:27, Manolo escribió:

>
> The branch GDI+soft of https://github.com/ManoloFLTK/fltk
>

> Please, give again your vote about committing these changes to FLTK 1.4
> TIA
>

+1.

[Bill Spitzak]

I would very much like to see this fixed for X as well. Not thrilled however that the programming of these systems is so bad that this makes any kind of visible peformance difference. That is horrible, considering this is like 30 year old technology!

--
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/906118b6-9a8e-89a3-c820-31b086ba19a4%40gmail.com.

[Bill Spitzak]

Also unclear if this is antialiasing filled shapes, yes or no?

[Manolo]

 I would very much like to see this fixed for X as well. Not thrilled however that the programming of these systems is so bad that this makes any kind of visible peformance difference. That is horrible, considering this is like 30 year old technology!

What would be the recommended technical solution under X: Cairo?

 

Also unclear if this is antialiasing filled shapes, yes or no?

I attach a snapshot of the output of the test/device program.
It contains a few filled shapes which are antialiased.

[Ian MacArthur]

On 27 May 2021, at 11:27, Manolo wrote:
>
> Please, give again your vote about committing these changes to FLTK 1.4

I vote +1 for inclusion.

Though (as folks may have inferred from my comments!) I’m not hugely keen on it being the default, since in some (hard to define, it seems...) edge cases it can miss out on the “fast” part of “fast and light”.

However, having it on by default during the 1.4 testing seems a sensible compromise.

[Ian MacArthur]

On 27 May 2021, at 18:16, Bill Spitzak wrote:
>
> I would very much like to see this fixed for X as well. Not thrilled however that the programming of these systems is so bad that this makes any kind of visible peformance difference. That is horrible, considering this is like 30 year old technology!

Yes, it is a pain. X is a moving target that seems to have no consensus solution beyond Cairo, which is slow...
MS seem to have had several stabs at this, and then seem to back off just before it actually comes to fruition - that certainly looks to be what happened with GDI+.
Their (MS) current scheme is Direct2D, but no one knows how to use that (apparently it plays nice with GDI and GDI+, and has a C API, but the examples I’ve seen don't intermix it with GDI or GDI+, and are written using their C++ API, which is in the usual hard-to-comprehend MS style... And which presumably is incompatible with the mingw* compilers that I use anyway...)

If I knew more about GL... that might be an option?
At least it is widely supported on many platforms (even Apple, at least for now...) and *usually* has the benefit of some h/w acceleration.

[Greg Ercolano]

    +1 for it being default until 1.4.0 release, at which point we can determine if it
    should be default or not for release.

-- 
Greg Ercolano, er...@seriss.com
Seriss Corporation
Tel: +1 626-576-0010 ext.8
Fax: +1 626-576-0020
Cel: +1 310-266-8906
Skype: ercolano77

      Rush Render Queue: http://seriss.com/rush/
          1A2 KSU Phone: http://seriss.com/1a2-ksu/
Optical Printer Control: http://seriss.com/opcs/

[Albrecht Schlosser]

On 5/27/21 11:02 PM Greg Ercolano wrote:
> On 5/27/21 1:02 PM, Ian MacArthur wrote:
>> On 27 May 2021, at 11:27, Manolo wrote:
>>> Please, give again your vote about committing these changes to FLTK 1.4
>> I vote +1 for inclusion.
>>
>> Though (as folks may have inferred from my comments!) I’m not hugely keen on it being the default, since in some (hard to define, it seems...) edge cases it can miss out on the “fast” part of “fast and light”.
>>
>> However, having it on by default during the 1.4 testing seems a sensible compromise.
>
>     +1 for it being default until 1.4.0 release, at which point we can
> determine if it
>     should be default or not for release.
>

I agree, +1 to add GDI+ and make it the default for now.

@Manolo: I suggest that you rebase and squash before merging the branch
because there have been a lot of changes that have been overwritten
later on. Ideally we'd have only one commit left that can be merged into
the master branch.

Please let me know (here or off-list) if you need help. Hint: `git
rebase -i master`, edit rebase instructions, ...

[Manolo]

Branch GDI+soft has now been rebased, squashed and merged to FLTK main branch (b027d2b ).

Thanks for your positive votes.