On 17 May 2021, at 08:54, 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
> 
> 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


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?






-- 
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/693F20BA-E5A0-498D-9477-836C8F7CC7CE%40gmail.com.