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

[MacArthur, Ian (Leonardo, UK)]

> Please pull from the git repository, to a01e74e or after. That should fix most of the issues reported.

OK, I now have...

$ git rev-parse HEAD
a01e74ed4d5b07cc2b111eaf7bc4469d5a514ffa

Deleted my build directory and regenerated for subsequent testing.


> - The missing pixel at rectangle top-left should be fixed.

Agree - this looks to be right, and the lines generally look very nice.

> - As you have reported, antialiasing was missing for rotated text. That's now fixed.

I'd say "mostly fixed" from my testing. It is better but...

> - A more intensive text antialiasing option is now used. All font sizes should now
> be antialiased. That's the same output I see when looking at system-generated text
> under Windows 10. Under XP, system-generated text seems less antialiased.
> I don't know the situation with Win8.
> - Yes, it's possible to add an API to turn antialiasing off. Let's first agree on the default
> behaviour.

> Mode 2 is in the current code. All text is antialiased, apparently the same way as system-generated text in Windows 10.

Hmm, on this machine (fairly high-end Win10 laptop, provided by my work - hence the annoying [General Use] tag in the subject line!) the text rendering in GDI+ is now better than the previous run, but still falls somewhat short of our "legacy" text handling on Win10, and is certainly *not* the same as the default text rendering on the host (i.e. what other non-fltk apps do.)

Here's some pictures. All are from "current" fltk-1.4, built with mingw32.

gdi+grab.png : Shows the rotated_text demo, with the font made large and rotated to -86. The left image is the GDI+ version, right image is our "legacy" behaviour. Here we see the GDI+ version shows some slight jaggies on both the horizontal and rotated text, as compared to the "legacy", though much reduced from the prior build I had, and clearly AA to some extent. The "legacy" case looks most like what other non-fltk apps render, AFAICT.


about-GDI+.png : Shows the "About..." box of the unittests dialog.
Here, the upper view is the GDI+ case, and for some reason a few of the words are misaligned, see the words "Unit", "correct" and "current" in the top line for examples. The lower view is the legacy format and looks OK.


lines-GDI+.png : Shows the unittests "Drawing Lines" tab, and the upper (GDI+) view is superior to the lower (legacy) view, and there are no obvious artefacts or missing pixels.


However, and this for me is a big one, going to the "schemes test" tab was a surprise - on the "legacy" version, switching between schemes from the drop-down just "instantly" refreshes the tab. With the GDI+ scheme view (particularly for "plastic" and "gleam") the redraw is so slow I actually see it drawing each widget. (I'd post a video, if I knew how to do that on this box!)

Is that just on this laptop - or do others see that effect?


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

[MacArthur, Ian (Leonardo, UK)]

> However, and this for me is a big one, going to the "schemes test" tab was
> a surprise - on the "legacy" version, switching between schemes from the
> drop-down just "instantly" refreshes the tab. With the GDI+ scheme view
> (particularly for "plastic" and "gleam") the redraw is so slow I actually
> see it drawing each widget. (I'd post a video, if I knew how to do that on
> this box!)

Managed to do a window grab as an mp4 - don’t know if this will upload or not but here goes anyway!

[Manolo]

Many thanks Ian for your tests. I had used a HighDPI screen where the variable vertical positionning

of small fonts don't occur. That should be repaired in the git repo (8673eff).
Rotated text should also be fixed.

I'll see if I can optimize the code for integral values of the scaling factor so the plastic theme draws faster.

[Greg Ercolano]

    I updated to latest and rebuilt in VS2017 and retested:

---
commit 09202a32b3c6fc7f209b375bf95646e2f4be8da7 (HEAD, origin/GDI+, GDI+)
Author: ManoloFLTK <41016272+...@users.noreply.github.com>
Date:   Fri Feb 5 12:09:38 2021 +0100

    Windows GDI+: fix Fl_GDIplus_Graphics_Driver::point()

    This has the plastic theme scale correctly.
---

    Responding to Ian's comments:

about-GDI+.png : Shows the "About..." box of the unittests dialog. 
Here, the upper view is the GDI+ case, and for some reason a few of the words are misaligned, see the words "Unit", "correct" and "current" in the top line for examples. The lower view is the legacy format and looks OK.

I see this too on Win8; the up/down text, almost as if it switches between superscript and subscript in between or short runs of several words:

This is the HTML viewer which renders "words at a time", where each word is separately drawn IIRC,
(due to how HTML handles word wrap and such) which might explain why the words themselves
are jumping up and down.

It seems like this up/down artifact is influenced by the shapes of letters, such as descenders/ascenders,
 caps, and such. Maybe the call that draws the words has some kind of new and clever vertical alignment
to make words fit just nice within multiline text, and that algoirthim is stymied by the way the HTML widget
draws words individually?

However, and this for me is a big one, going to the "schemes test" tab was a surprise - on the "legacy" version, switching between schemes from the drop-down just "instantly" refreshes the tab. With the GDI+ scheme view (particularly for "plastic" and "gleam") the redraw is so slow I actually see it drawing each widget. (I'd post a video, if I knew how to do that on this box!) 

Is that just on this laptop - or do others see that effect?

    I see it too on my win8 box -- very similar to the mp4 video you posted. Interesting!

[Albrecht Schlosser]

On 2/5/21 3:50 PM Manolo wrote:
> I had used a HighDPI screen where the
> variable vertical positionning
> of small fonts don't occur. That should be repaired in the git repo
> (8673eff).
> Rotated text should also be fixed.

I can see improvements on rotated text, as others noted already, but it
doesn't seem to be "perfect" yet.

Adding some more observations from ...

commit 8673eff3afe12724afc775175eabc3670bed1e0c (HEAD -> GDI+, origin/GDI+)
Author: ManoloFLTK <41016272+...@users.noreply.github.com>
Date: Fri Feb 5 15:45:39 2021 +0100

Windows GDI+: fix vertical position of small font sizes and rotated
text quality.


Note that all tests are from test/unittests w/o zooming but some of the
images have been zoomed in Gimp for better visibility.


(1) circles-and-arcs.png:

Circles and arcs appear to be 1 pixel too large, at least I can see some
red pixels in test/unittests.


(2) text-extents.png:

Looking at the red and green rectangles I assume there's something wrong
with fl_measure() and fl_text_extents(). Both seem to return too small
values.


(3) text-maybe-wider-than-before.png:

I don't have a direct comparison at hand but it seems that the text is a
little wider than before (see red circles). I also assume that (2) leads
to somewhat asymmetrical text appearance in the right two rows of
buttons (text seems to be shifted right a little bit).


Other than that, shading in "gleam" boxes seems to be much better than
ever before at different zoom levels.

Awesome!

[Albrecht Schlosser]

On 2/5/21 1:06 PM 'MacArthur, Ian (Leonardo, UK)' via fltk.coredev wrote:
>> However, and this for me is a big one, going to the "schemes test" tab was
>> a surprise - on the "legacy" version, switching between schemes from the
>> drop-down just "instantly" refreshes the tab. With the GDI+ scheme view
>> (particularly for "plastic" and "gleam") the redraw is so slow I actually
>> see it drawing each widget. (I'd post a video, if I knew how to do that on
>> this box!)

Works almost instantaneously for me in a Virtualbox VM on a recent (~15
months) notebook with "Intel core i7 8th gen" using no more than 2 cores
in Virtualbox (2 GB memory).

The only scheme that *feels* minimally slower (1/100 sec. ???) is 'plastic'.

> Managed to do a window grab as an mp4 - don’t know if this will upload or not but here goes anyway!

Got it, nice video. But the delay is significant.

[Albrecht Schlosser]

On 2/5/21 6:19 PM Albrecht Schlosser wrote:
> On 2/5/21 1:06 PM 'MacArthur, Ian (Leonardo, UK)' via fltk.coredev wrote:
>>> However, and this for me is a big one, going to the "schemes test"
>>> tab was
>>> a surprise - on the "legacy" version, switching between schemes from the
>>> drop-down just "instantly" refreshes the tab. With the GDI+ scheme view
>>> (particularly for "plastic" and "gleam") the redraw is so slow I
>>> actually see it drawing each widget.
>

> Works almost instantaneously for me in a Virtualbox VM on a recent (~15
> months) notebook with "Intel core i7 8th gen" using no more than 2 cores
> in Virtualbox (2 GB memory).

... which means the VM has 2 GB of total 16 GB, BTW.

Related: I noticed that test/unittests.exe runs with a significant CPU
load (18-28%) when doing *nothing*. I didn't test yet if other test
programs have a similar effect.

Ian, if you had one such program stealing CPU cycles this could maybe
cause such issues. Windows is not very good at time sharing AFAICT.
Also, virus checkers can get active. Can you check with task manager?

All:

Maybe not directly related with the CPU issue but with test/unittests:
it's a known problem that unittests can crash at exit, see issue #89:
https://github.com/fltk/fltk/issues/89

Greg suggested a fix (or workaround) but this is not yet fully
tested/verified. If you experience such crashes (I did at least 2 or 3
times) everything to find the real cause would be helpful. You may want
to add info to the GitHub issue. TIA.

Note: in my tests I could maybe (don't remember exactly) observe that
such a unittests process closed its window but didn't terminate and spin
around until I killed it.

Again related to Ian's issue: if this happened for you it might be a
reason for your slow drawings?

[Greg Ercolano]

Managed to do a window grab as an mp4 - don’t know if this will upload or not but here goes anyway!

Got it, nice video. But the delay is significant.

    Ya, and my results on Win 8 on a Mac Mini were similar to his video using Gleam.

    In fact, all the widget drawing under the "schemes" test I could watch the widgets "wipe" on screen.
    Even "none". Both plastic and gleam were slow, but definitely gleam was the slowest. And when I
    resize the window while gleam is activated, you can really see how slow it is.. it actually pauses the
    resizing during.

    It's strange though, if I open 'tree' and resize the window, it has a /lot/ of widgets, but still renders
    quickly even during resizes. And if I invoke it with "tree -scheme gleam", it still renders quickly even on resize.

    At first I thought it might be Double vs. Single buffered Fl_Windows, but both unittests and tree
    use Fl_Double_Window from what I can tell, so it's actually kinda weird to me that we can 'see'
    the widgets drawing at all in unittests, actually. Shouldn't it be drawing offscreen until done?

[Ian MacArthur]

On 5 Feb 2021, at 17:19, Albrecht Schlosser wrote:
>
> Works almost instantaneously for me in a Virtualbox VM on a recent (~15 months) notebook with "Intel core i7 8th gen" using no more than 2 cores in Virtualbox (2 GB memory).
>
> The only scheme that *feels* minimally slower (1/100 sec. ???) is 'plastic’.

I was testing with two builds of fltk, one stock (tip of git as of this morning) one the then-tip of Manolo’s GDI+ repo.

The stock GDI build was “instantaneous” for all schemes, whereas the GDI+ build was visibly slow, especially for plastic and gleam.
Of these, I’d say that gleam was the worse of the two, really.

I don’t think it was a loading issue, or a virus scanner issue because it’s my work machine (not my own) and is pretty decent for a laptop (6 cores, Nvidia GPU, plenty RAM, SSD etc.) and is set up for “developer use” which means there's a sandbox area where apps are "immune” to the virus scanner etc...

AFAIK, both builds use the same options and settings, so I *assume* the performance discrepancy arises due to the GDI vs. GDI+ differences, but it may be some other factor...

Basically, I do not know.

[Greg Ercolano]

 

Related: I noticed that test/unittests.exe runs with a significant CPU load (18-28%) when doing *nothing*. I didn't test yet if other test programs have a similar effect.

    Huh, I can not replicate that on Win8 (tested with both GDI+ and GDI)

    When I run unittests with the taskmanager open showing "Performance", the cpu is very idle
    when I just leave the window open and don't do anything (like leaving the mouse alone)

    And when I look at the per-process report, unittests is 0% cpu.

    Interestingly this is a 64bit machine, but "unittests.exe" in the task manager process report is showing
    "unittests (32bit)". So apparently my VS2017 is building 32bit apps instead of 64. I don't see "Win64"
    as an option under the pulldown menu, so maybe this machine doesn't have the 64bit "option" installed.

[Greg Ercolano]

On 2/5/21 9:58 AM, Ian MacArthur wrote:

The stock GDI build was “instantaneous” for all schemes, whereas the GDI+ build was visibly slow, especially for plastic and gleam.
Of these, I’d say that gleam was the worse of the two, really.

    I  see the same.

    Curious: when you resize the unittests screen while gleam is up, do you get "pauses" during the resize
    for each "screen redraw"?

    Then try running 'tree -scheme gleam' and resize, do you see similar slowness, or is it 'fast'?

    I'm trying to understand why we can "see" the widgets drawing.. unittests is an Fl_Double_Window app.
    Oh wait! unittests_schemes uses an Fl_Window as a subwindow:

$ grep Fl_Window unit*cxx
unittest_schemes.cxx:    Fl_Window *subwin = new Fl_Window(X,Y+30,W,H-30);

    That would explain seeing the redraws I suppose.

[Ian MacArthur]

On 5 Feb 2021, at 18:01, Greg Ercolano wrote:

 

Related: I noticed that test/unittests.exe runs with a significant CPU load (18-28%) when doing *nothing*. I didn't test yet if other test programs have a similar effect.

    Huh, I can not replicate that on Win8 (tested with both GDI+ and GDI)

    When I run unittests with the taskmanager open showing "Performance", the cpu is very idle

Yes, that tallies with my experience. Basically, no CPU load on my Win10 laptop test.

I’ve seen VirtualBox chew CPU before, even when I was doing “nothing”, so it may be that which is affecting Albrecht’s tests?

    Interestingly this is a 64bit machine, but "unittests.exe" in the task manager process report is showing
    "unittests (32bit)". So apparently my VS2017 is building 32bit apps instead of 64. I don't see "Win64"
    as an option under the pulldown menu, so maybe this machine doesn't have the 64bit "option" installed.

Is there not some incantation or other you need to give to cmake to make it generate both the 32 and 64 build targets?

(Note: I do not know what I am talking about.)

[Greg Ercolano]

On 2/5/21 10:05 AM, Greg Ercolano wrote:

    Oh wait! unittests_schemes uses an Fl_Window as a subwindow:

$ grep Fl_Window unit*cxx
unittest_schemes.cxx:    Fl_Window *subwin = new Fl_Window(X,Y+30,W,H-30);

    That would explain seeing the redraws I suppose.

    OK, here's an interesting test.. for giggles I changed unittest_schemes.cxx to use an Fl_Double_Window
    and now it draws gleam really fast, even during window resizes.

    So I guess offscreen drawing is a lot faster than onscreen drawing.

[Manolo]

On Friday, February 5, 2021 at 6:11:59 PM UTC+1 Albrecht Schlosser wrote:

(2) text-extents.png:
Looking at the red and green rectangles I assume there's something wrong
with fl_measure() and fl_text_extents(). Both seem to return too small
values.

Oh! fl_text_extents was perfect before! Fixing one place has ruined another.

[Ian MacArthur]

Oh... that is interesting. I wonder if it is interacting with the screen compositor system on Win8/Win10 in some way, then? That might even account for why Albrecht didn’t see it, as ISTR that Vbox does something weird with that.

The legacy GDI scheme is hardware rendered, so probably interacts better with the composition.

[Ian MacArthur]

On 5 Feb 2021, at 18:05, Greg Ercolano wrote:
>
> Curious: when you resize the unittests screen while gleam is up, do you get "pauses" during the resize
> for each "screen redraw"?
>
> Then try running 'tree -scheme gleam' and resize, do you see similar slowness, or is it 'fast’?

Sorry - that machines inaccessible right now; but will try once I’m back on...

[Ian MacArthur]

Both fl_text_extents and fl_measure seem to be awry in Albrecht’s shots... Are we measuring the “wrong thing” now or something?
Or... maybe there’s something odd with the way the VM that Albrecht uses measures text?

[Greg Ercolano]

On 2/5/21 10:06 AM, Ian MacArthur wrote:

Is there not some incantation or other you need to give to cmake to make it generate both the 32 and 64 build targets?

(Note: I do not know what I am talking about.)

    Looks like the cmake flag "-A x64" enables 64bit builds for VS.

    We should probably mention this in the README.CMake.txt.

[Greg Ercolano]

    I'm not seeing the problem Albrecht is seeing with the unittests -> Text rendering.

    Here's my screenshot (win8 / VS 2017 32bit / gdi+ / git 09202a32b3c6):

[Albrecht Schlosser]

On 2/5/21 7:06 PM Ian MacArthur wrote:
> On 5 Feb 2021, at 18:01, Greg Ercolano wrote:
>>
>>>
>>> Related: I noticed that test/unittests.exe runs with a significant
>>> CPU load (18-28%) when doing *nothing*. I didn't test yet if other
>>> test programs have a similar effect.
>>

>>     Huh, I can /_not_/ replicate that on Win8 (tested with _both_ GDI+

>> and GDI)
>>
>>     When I run unittests with the taskmanager open showing
>> "Performance", the cpu is very idle
>>
>
> Yes, that tallies with my experience. Basically, no CPU load on my Win10
> laptop test.

Sorry for any unwanted confusion. I didn't mean that it happened
*always*. I saw it at least twice and IIRC always after leaving the VM
alone and doing something else.

Side note: I can *hear* when such things happen because my notebook fan
starts making (not much, but hearable) noise.

I'll do some more tests and report if I can find a reproducer...

> I’ve seen VirtualBox chew CPU before, even when I was doing “nothing”,
> so it may be that which is affecting Albrecht’s tests?

I've seen that too, but mostly with Windows VM's. I have three Linux
VM's (Debian Buster, Ubuntu 20.04 LTS, and Ubuntu 20.10) that don't
exhibit such a behavior.

<OT>
Windows *often* does "something" when you leave the system alone. I'm
used to starting the system monitor to see what it did when it's heavily
using my notebook. When I "come back" I can see high (say: 30%) CPU load
*until* I click somewhere - then the load goes down magically. What are
they doing ???
That's one of the reasons why I switched entirely from Windows to Linux.

See attached image for such an event. The Windows virus checker was
active (I could still see it in the monitor) and it stopped its activity
as soon as I clicked into a window. While this is basically as intended,
it's still annoying.

I could even notice sluggishness in my work elsewhere on this machine
while this happened. Virtualbox took up to "360 %" CPU load (i.e. almost
four cores) at that time.

I was wrong WRT the VM's resources: it's configured to use 4 of my 8
cores and 4 of my 16 GB memory. Maybe I should reduce this...
</OT>

>>     Interestingly this is a 64bit machine, but "unittests.exe" in the
>> task manager process report is showing
>>     "unittests (32bit)". So apparently my VS2017 is building 32bit
>> apps instead of 64. I don't see "Win64"
>>     as an option under the pulldown menu, so maybe this machine
>> doesn't have the 64bit "option" installed.

CMake can create only one target build system, either "Win32" or "x64"
in one project. If you use the CMake GUI you can select it easily. I
don't know which option(s) to use when running CMake on the commandline.

See attached image "cmake.png".

I'm pretty sure the command line works as well (unless you really lack a
64-bit build environment) but, as said before, I don't know the "magic"
switches.

[Albrecht Schlosser]

As I wrote before I was using a later version:

commit 8673eff3afe12724afc775175eabc3670bed1e0c (HEAD -> GDI+, origin/GDI+)
Author: ManoloFLTK <41016272+...@users.noreply.github.com>
Date: Fri Feb 5 15:45:39 2021 +0100

Windows GDI+: fix vertical position of small font sizes and rotated
text quality.

See also Manolo's comment (it seems to be a regression).

[Greg Ercolano]

On 2/5/21 10:38 AM, Albrecht Schlosser wrote:

<OT>
Windows *often* does "something" when you leave the system alone. I'm used to starting the system monitor to see what it did when it's heavily using my notebook. When I "come back" I can see high (say: 30%) CPU load *until* I click somewhere - then the load goes down magically. What are they doing ???

    What I've found is it's either the search indexer or windows update.
    But there's other stuff like virus scans and such. The smarter of these tools try to step out of the way
    if there's a sign of user activity, then jump back on when idle.

    Esp if you're like me and don't leave a windows system on except when you need it, you boot it expecting
    to use the machine right away, but it immediately realizes it hasn't been on for a while and tries to to update
    everything (search index, OS updates, virus scans..)

That's one of the reasons why I switched entirely from Windows to Linux.

    Ya, don't even get me started, lol..
    but having been forced to use windows for situations (such as now), I've learned over time what
    its wiley ways are.

    If you dig down, you can turn this stuff off (updates, indexer, virus checkers/windows defender)..

    Interestingly this is a 64bit machine, but "unittests.exe" in the task manager process report is showing
    "unittests (32bit)". So apparently my VS2017 is building 32bit apps instead of 64. I don't see "Win64"
    as an option under the pulldown menu, so maybe this machine doesn't have the 64bit "option" installed.

CMake can create only one target build system, either "Win32" or "x64" in one project. If you use the CMake GUI you can select it easily. I don't know which option(s) to use when running CMake on the commandline.

See attached image "cmake.png".

    I was able to build fltk with x64 using cmake's "-A x64" flag to create an fltk.sln.

    With that, inside VS, the x64 option was default, and it built fine.

    Didn't seem to affect performance, similar results.

[Greg Ercolano]

On 2/5/21 10:45 AM, Albrecht Schlosser wrote:

On 2/5/21 7:34 PM Greg Ercolano wrote:

     Here's my screenshot (win8 / VS 2017 32bit / gdi+ / git 09202a32b3c6):

As I wrote before I was using a later version:

commit 8673eff3afe12724afc775175eabc3670bed1e0c (HEAD -> GDI+, origin/GDI+)

    Ugh, what's the "right" way to pull the latest from his repo when on branch gdi+, so that,
    no questions asked, it just does almost the equivalent of a re-clone, but leaves me on the
    HEAD of the branch I'm on?

    Whenever I can't get it to work, I just resort to 'git clone', sigh..

[imm]

On Fri, 5 Feb 2021, 19:00 Greg Ercolano,  wrote:

    Ugh, what's the "right" way to pull the latest from his repo when on branch gdi+, so that,
    no questions asked, it just does almost the equivalent of a re-clone, but leaves me on the
    HEAD of the branch I'm on?

    Whenever I can't get it to work, I just resort to 'git clone', sigh..

Huh, I dunno. When I've got a branch checked out it generally just tracks the remote, so a simple "git pull" does the job and updates the branch I'm on.

Is that not working?

-- 
Ian
From my Fairphone FP3

[Albrecht Schlosser]

Yep, that *should* do it. If not you can also add the remote and branch
to git pull, e.g.

$ git checkout GDI+
$ git pull <manolos-fork> GDI+

where "<manolos-fork>" is the "remote" name of Manolo's fork (maybe
"origin" if you cloned from it in the first place) and "GDI+" is the branch.

[Greg Ercolano]

    "git pull" only seems to work if everything is untouched. But if you touch enough stuff it barfs,
    and usually 'git pull --ff-only' is the right thing, but I was getting errors about the branch I was on, e.g.

$ git pull --ff-only
There is no tracking information for the current branch.
Please specify which branch you want to merge with.


    I don't even want to go down the git rabbit hole of what that means, just not in the mood to get
    distracted, so I just resort to stronger measures. I think what I'm looking for is:

        git fetch origin && git reset --hard origin/gdi+

    ..a "no questions asked" get me to the remote's current branch, but leave my build directories alone
    so I can still run the old binaries I've built previously.

    That seemed to get me to 8673eff3afe12724 which according to github is manolo's latest
    on the gdi+ branch, and is what Albrecht reported he used.

    So I'm rebuilding with that, using the x64 flag for cmake from now on, e.g.

        cmake -G "Visual Studio 15 2017" -A x64 -D CMAKE_BUILD_TYPE=Release -D OPTION_USE_GDIPLUS=ON ..

    Just did that, and now I can replicate Albrecht's issue with the unittests -> rendering text:

    I assume Manolo noticed it too, based on his reply.

[Manolo]

With git commit 2633e5b, you should have something that can both draw small fonts

without moving some words up and down, and compute fl_text_extents correctly.

The solution is to draw text with mode TextRenderingHintAntiAlias when fontsize ≤ 13

and with mode TextRenderingHintClearTypeGridFit for larger fonts. There must be

a better solution, but I did not find it.

[Albrecht Schlosser]

On 2/5/21 8:42 PM Greg Ercolano wrote:
>
>     "git pull" only seems to work if everything is untouched. But if
> you touch enough stuff it barfs,

>     and usually '*git pull --ff-only*' is the right thing, but I was

> getting errors about the branch I was on, e.g.
>
> $ git pull --ff-only
> There is no tracking information for the current branch.
> Please specify which branch you want to merge with.

That's what I wrote about in my reply. Just add the remote ("origin") as
the first argument and the remote branch ("GDI+", all caps) and it
*should* work. If you really used "gdi+" (lowercase) that might have
caused your issue in the first place (I *think* branch names are case
sensitive).

> I don't even want to go down the git rabbit hole of what that means,

OK, then I won't tell you. ;)

> just not in the mood to get
>     distracted, so I just resort to stronger measures. I think what I'm
> looking for is:
>
>         git fetch origin && git reset --hard origin/gdi+

Did it really work with lowercase "gdi+"? [not in my test]

albrecht@swift:/git/fltk/manolo$ git fetch
remote: Enumerating objects: 54, done.
remote: Counting objects: 100% (54/54), done.
remote: Compressing objects: 100% (37/37), done.
remote: Total 37 (delta 33), reused 4 (delta 0), pack-reused 0
Unpacking objects: 100% (37/37), 5.04 KiB | 103.00 KiB/s, done.
From https://github.com/ManoloFLTK/fltk
a01e74ed4..2633e5b67 GDI+ -> origin/GDI+

-------------------------^^^^----------^^^^^^^^^^^

albrecht@swift:/git/fltk/manolo$ git status
On branch GDI+
Your branch is behind 'origin/GDI+' by 10 commits, and can be
fast-forwarded.
(use "git pull" to update your local branch)
---^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In this case it should be fine to do that (since CMake says: "...can be
fast-forwarded").

>     ..a "no questions asked" get me to the remote's current branch, but
> leave my build directories alone
>     so I can still run the old binaries I've built previously.

Caution: "git reset --hard" does what you tell it to do. It's really a
*HARD* *RESET*, so if you have edited files in your working copy (as you
wrote above - maybe WRT other cases) it will *RESET* all files in your
working copy!

However you're right, the build folder is not affected.

>
>     That seemed to get me to 8673eff3afe12724 which according to github
> is manolo's latest
>     on the gdi+ branch, and is what Albrecht reported he used.

Yep, but no longer true. Manolo committed meanwhile

2633e5b67 2021-02-05 20:43:47 +0100 ManoloFLTK - Windows GDI+:
new way to deal with small fonts without destroying text_extents.

I did alread pull that, will give it a try...

[Albrecht Schlosser]

On 2/5/21 8:56 PM Manolo wrote:
> With git commit 2633e5b, you should have something that can both draw
> small fonts
> without moving some words up and down, and compute fl_text_extents
> correctly.

Wow, that was quick!

> The solution is to draw text with mode TextRenderingHintAntiAlias when
> fontsize ≤ 13
> and with mode TextRenderingHintClearTypeGridFit for larger fonts. There
> must be a better solution, but I did not find it.

Yep, that really doesn't sound reasonable, but for now, until there's a
better solution, we can at least test. Thanks.

[Manolo]

I also have a git-related question.

Consider 2 local git repos, clones of https://github.com/ManoloFLTK/fltk , on two different computers.

One is where the development of branch GDI+ goes.The other is used only for testing.

After repo1 has pushed, repo2 can pull and get the new GDI+ code.

Now, suppose new code has been pushed to https://github.com/fltk/fltk

I apply, in repo1, what Albrecht taught me to propagate these changes to ManoloFLTK and its GDI+ branch:

git remote -v
    manolo    https://github.com/ManoloFLTK/fltk.git (fetch)
    manolo    https://github.com/ManoloFLTK/fltk.git (push)
    origin    https://github.com/fltk/fltk.git (fetch)
    origin    https://github.com/fltk/fltk.git (push)
git checkout master
git status
git fetch
git status
git pull
git push manolo master
git rebase master GDI+

git status
    On branch GDI+

git push -f manolo GDI+

At that point, repo1 contains all new FLTK stuff and the latest development for GDI+

The problem is when I turn to repo2:

git status

  On branch GDI+

git pull

 ---> git sees a merge operation.

Why is it so?

How can I just pull from ManoloFLTK what has changed and write that in repo2?

[Greg Ercolano]

On 2/5/21 12:04 PM, Albrecht Schlosser wrote:

On 2/5/21 8:42 PM Greg Ercolano wrote:

     "git pull" only seems to work if everything is untouched. But if you touch enough stuff it barfs,
     and usually '*git pull --ff-only*' is the right thing, but I was getting errors about the branch I was on, e.g.

$ git pull --ff-only
There is no tracking information for the current branch.
Please specify which branch you want to merge with.

That's what I wrote about in my reply. Just add the remote ("origin") as the first argument and the remote branch ("GDI+", all caps) and it *should* work. If you really used "gdi+" (lowercase) that might have caused your issue in the first place (I *think* branch names are case sensitive).

    Mmm, maybe I've pulled the branch as lowercase, but then can update it as lowercase.
    *sigh*

I don't even want to go down the git rabbit hole of what that means,

OK, then I won't tell you. ;)

    Ya, I just won't retain it. I just need a short answer so my brain can remember it.

    Basically overwrite all FLTK's code with the current, abandoning any small tweaks I might have,
    just like a clone, basically. But not loosing my build dirs or other non-git files.

    I'm usually very careful when I have code I want to keep, using merges or such.
    And when unsure, I make copies of everything first in a tar file or some such.

just not in the mood to get
     distracted, so I just resort to stronger measures. I think what I'm looking for is:

         git fetch origin && git reset --hard origin/gdi+

Did it really work with lowercase "gdi+"? [not in my test]

    It did; just did it now to get to manolo's recent mods:

erco@win8 MINGW64 ~/fltkGDI+2
$ git fetch origin
remote: Enumerating objects: 15, done.
remote: Counting objects: 100% (15/15), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 8 (delta 7), reused 1 (delta 0), pack-reused 0
Unpacking objects: 100% (8/8), 963 bytes | 2.00 KiB/s, done.
From https://github.com/ManoloFLTK/fltk
   8673eff3a..2633e5b67  GDI+       -> origin/GDI+

erco@win8 MINGW64 ~/fltkGDI+2
$ git reset --hard origin/gdi+
HEAD is now at 2633e5b67 Windows GDI+: new way to deal with small fonts without destroying text_extents.

erco@win8 MINGW64 ~/fltkGDI+2
$ git log
commit 2633e5b673871dd294b823096a2af5d416c154dc (HEAD -> GDI+, origin/GDI+)

    Beats me, maybe it works in this particular syntax, or maybe it's ignoring the branch name
    and just falling back to my current branch.

    It's certainly not complaining, so I dunno..

Caution: "git reset --hard" does what you tell it to do. It's really a *HARD* *RESET*, so if you have edited files in your working copy (as you wrote above - maybe WRT other cases) it will *RESET* all files in your working copy!

    Yep, that's what I want -- overwrite all the tweaks I've made for quick tests to be sure I'm building with the
    same fltk code everyone else is, my tweaks be damned.

[Greg Ercolano]

Here's a quick video showing resizing unittests -> scheme in latest gdi+ mode for both "gleam"
and "none" on my win8 machine:

http://seriss.com/people/erco/tmp/unittest-scheme-resize-02-05-2021.webm

The clock's second hand in the background ran smoothly through the whole process,
so if the video playback shows the clock hand being jerky, let the video reply a few times
until it's smooth.

[Greg Ercolano]

On 2/5/21 11:56 AM, Manolo wrote:

With git commit 2633e5b, you should have something that can both draw small fonts

without moving some words up and down, and compute fl_text_extents correctly.

    Yes, unittests now working again with text rendering:

    ..and no text jumping up and down in the unittests -> About screen.

    I'm moving on to deal with other things today, will check back in later tonight/tomorrow.

[Albrecht Schlosser]

On 2/5/21 9:26 PM Manolo wrote:
> I also have a git-related question.
>
> Consider 2 local git repos, clones of https://github.com/ManoloFLTK/fltk
> , on two different computers.
> One is where the development of branch GDI+ goes.The other is used only
> for testing.
> After repo1 has pushed, repo2 can pull and get the new GDI+ code.
>
> Now, suppose new code has been pushed to https://github.com/fltk/fltk

> <https://github.com/ManoloFLTK/fltk>

> I apply, in repo1, what Albrecht taught me to propagate these changes to
> ManoloFLTK and its GDI+ branch:
>
> git remote -v
>     manolo    https://github.com/ManoloFLTK/fltk.git (fetch)
>     manolo    https://github.com/ManoloFLTK/fltk.git (push)
>     origin    https://github.com/fltk/fltk.git (fetch)
>     origin    https://github.com/fltk/fltk.git (push)
> git checkout master
> git status
> git fetch
> git status
> git pull
> git push manolo master
> git rebase master GDI+
> git status
>     On branch GDI+
> git push -f manolo GDI+
>
> At that point, repo1 contains all new FLTK stuff and the latest
> development for GDI+

Yep, that looks fine.

> The problem is when I turn to repo2:
> git status
>   On branch GDI+
> git pull
>  ---> git sees a merge operation.
> Why is it so?

This is so because your local branch GDI+ in repo2 is still on the old
base where it branched off.

But I'm not sure how your repo2 is set up. What is the origin, which is
the remote you want to pull from?

> How can I just pull from ManoloFLTK what has changed and write that in
> repo2?

Assuming your repo2's origin is your ManoloFLTK clone...

git status
> On branch GDI+

# get all updates w/o doing a merge (just fetch)

git fetch
... shows progress and some SHA1's ...

git status
... likely says that your branches diverged and some advice ...

I don't know what git suggests (would have to test it) but it's probably
not what you want (results in a merge).

Instead you can do what Greg did (git reset --hard) or you can modify
your local branch to reflect the status of the remote branch (which has
been rebased).


(1) As Greg did (reset --hard):

WARNING: Make sure you don't have local modifications you want to keep
in your working copy (only modifications are important, untracked files
are not an issue, they will not be touched). You can either use `git
stash` (and later `git stash pop` to restore) or you can copy these
files elsewhere or use git diff or whatever. You can even commit local
changes to another temporary branch.

Just to be sure not to lose valid changes!

Then:

git checkout GDI+ # if not done already
git status # just to be sure

Now the dangerous (not revertible) command:

git reset --hard REMOTE/GDI+

This resets your local branch to commit "REMOTE/GDI+" which appears to
be what you want. It would also overwrite all modified files in your
working copy.

Replace "REMOTE" with the correct remote name, likely "origin".

That should be it (1).


(2) Modify your local branch GDI+ to point at the correct commit:

git checkout master # *must* checkout *another* branch
git fetch [origin] # gets all new commits as before

Now modify your local branch: this does not change your working copy
(which is at 'master')

git branch -f GDI+ origin/GDI+

This *forces* your local branch GDI+ to point at the same commit as
"origin/GDI+". It just moves its "HEAD". This is way less "dangerous"
than method (1).

Then checkout your "corrected" local branch GDI+ again.

git checkout GDI+

That should be it (2).


Note: no guarantees, that's all off the top of my head but I'm pretty
sure it should work at least with minor modifications.

[Albrecht Schlosser]

On 2/5/21 9:27 PM Greg Ercolano wrote:
>
>>> I think what I'm looking for is:
>>>
>>>          git fetch origin && git reset --hard origin/gdi+
>>
>> Did it really work with lowercase "gdi+"? [not in my test]
>
>     It did; just did it now to get to manolo's recent mods:
>
> erco@win8 MINGW64 ~/fltkGDI+2

> $ *git fetch origin*

> remote: Enumerating objects: 15, done.
> remote: Counting objects: 100% (15/15), done.
> remote: Compressing objects: 100% (8/8), done.
> remote: Total 8 (delta 7), reused 1 (delta 0), pack-reused 0
> Unpacking objects: 100% (8/8), 963 bytes | 2.00 KiB/s, done.
> From https://github.com/ManoloFLTK/fltk
>    8673eff3a..2633e5b67  GDI+       -> origin/GDI+
>
> erco@win8 MINGW64 ~/fltkGDI+2

> $ *git reset --hard origin/gdi+*

> HEAD is now at 2633e5b67 Windows GDI+: new way to deal with small fonts
> without destroying text_extents.

Ouch! I can verify that it works with lowercase on Windows but I also
double checked that it doesn't work on Linux. That means there's an
inconsistency between Windows and Linux in that branch names are case
insensitive on Windows but case sensitive on Linux. You can add two
branches where only the case differs on Linux but you won't be able to
pull one or the other on Windows. Short test:

--- Linux ---

Linux $ git br TEST1
Linux $ git br test1
Linux $ git br -f test1 origin/branch-1.3
Branch 'test1' set up to track remote branch 'branch-1.3' from 'origin'.
Linux $ git rev-parse TEST1
246291fe51734f9be73f457a7c4da00f2413a3dd
Linux $ git rev-parse test1
02e4b8f98056da7a37d459283b17521d7f5e3e8d

--- Windows ---

Windows $ git br TEST1
Windows $ git br test1
fatal: A branch named 'test1' already exists.


I think this is a serious git bug (although it's not wise to do such
things like two branch names that only differ in case).

[Albrecht Schlosser]

On 2/5/21 9:59 PM Greg Ercolano wrote:
> Here's a quick video showing resizing unittests -> scheme in latest gdi+
> mode for both "gleam" and "none" on my win8 machine:
>
> http://seriss.com/people/erco/tmp/unittest-scheme-resize-02-05-2021.webm

That's definitely different from what I see in my Win10 Virtualbox VM. I
uploaded a video here:
https://www.sendvid.com/zvmk1utg

Drawing happens smoothly when resizing the window in all schemes.

[Greg Ercolano]

    I get the same flicker result the video shows on a different machine; different hardware, different OS (Windows 7).
    Flickers noticeably with all schemes (including none) and equally badly with gleam, but the non GDI+
    is very responsive.

    Albrecht, maybe test without the VM, as we can't compare driver behavior that way.

    Of interest: on the Windows 7 machine I can replicate the issue 89 unittest crashing problem pretty easily,
    so that's interesting my Win8 machine doesn't show it, but Win7 does.

    Normally I only use the Win7 for EE/Cad, so I keep compilers and software related projects off it,
    but made an exception to do this test.

[Greg Ercolano]

On 2/6/21 3:35 PM, Greg Ercolano wrote:

    Of interest: on the Windows 7 machine I can replicate the issue 89 unittest crashing problem pretty easily,
    so that's interesting my Win8 machine doesn't show it, but Win7 does.

    Hmm, looking closely at this issue89 crashing thing: I have three executables:

unittests-gdiplus.exe         -- GDI+ enabled, 64bit
unittests-nogdi.exe           -- GDI+ disabled, 64bit
unittests-issue89-fix.exe     -- issue89 branch from my fork

    The unittests-gdiplus.exe crashes 100% of the time on exit on my Win7 machine;
    I can't seem to get it NOT to crash.

    Same binary (it's on a network drive) runs fine on Win8 with no crashes.
    Or so it seemed! While I get /no dialog/ about it crashing, or any indication or warning,
    I decided to check the Windows Event Manager, and it IS showing that binary crashing
    every time:

Faulting application name: unittests-gdiplus.exe, version: 0.0.0.0, time stamp: 0x601dac35
Faulting module name: ntdll.dll, version: 6.3.9600.17031, time stamp: 0x530895af
Exception code: 0xc0000005
Fault offset: 0x0000000000065e8e
Faulting process id: 0x1444
Faulting application start time: 0x01d6fcf576c21c7a
Faulting application path: C:\net\tmp\vc\unittests-gdiplus.exe
[..]

    So it's been crashing every time and I never knew it because there was no indication.

    So I don't know what that's all about.. whether I have VS open or not, the crashes
    don't generate a dialog (weird!) but do on Win7. There must be some registry thing
    that's hiding crash dialogs or something.

    The other two bianries don't crash at all on Win7.

    I'd certainly expect the issue89 not to crash, but it's odd the nogdi one
    doesn't crash.

    There must be a randomness to the issue89 problem that's impacted by the
    contents of the binary itself.

    So I'm now +1 for applying the issue89 patch, as the crashing has been hidden from
    me all this time.

[Albrecht Schlosser]

On 2/7/21 12:35 AM Greg Ercolano wrote:
>
> On 2/6/21 2:13 PM, Albrecht Schlosser wrote:
>> On 2/5/21 9:59 PM Greg Ercolano wrote:
>>> Here's a quick video showing resizing unittests -> scheme in latest
>>> gdi+ mode for both "gleam" and "none" on my win8 machine:
>>>
>>> http://seriss.com/people/erco/tmp/unittest-scheme-resize-02-05-2021.webm
>>
>> That's definitely different from what I see in my Win10 Virtualbox VM.
>> I uploaded a video here:
>> https://www.sendvid.com/zvmk1utg
>>
>> Drawing happens smoothly when resizing the window in all schemes.
>
>
>     I get the same flicker result the video shows on a different
> machine; different hardware, different OS (Windows 7).
>     Flickers noticeably with all schemes (including none) and equally
> badly with gleam, but the non GDI+
>     is very responsive.
>
>     Albrecht, maybe test without the VM, as we can't compare driver
> behavior that way.

That experiment took almost 7 hours (clock time) for updating my "bare
metal" older (Win7 times) PC which is now also running Win10. I had Win
10 "2004" (spring 2020) running with the latest updates in September
2020. I updated to the latest patches only, update "Version 20H2" still TBD.

OK, my two VS versions on this system are VS 2008 and VS 2010.
Unfortunately I couldn't build OOTB, neither master nor Manolo's GDI+
branch. First surprise: these versions (or at least 2010 with its SDK)
don't know round() even if 'math.h' is included, hence I had to fix this
"manually". The applied hack works but I'm still looking for a better
solution...

Note: MS docs are currently available for VS 2015, 2017, and 2019 only,
so we don't know if this (missing round()) is "intentional" or not. Docs
seem to indicate that there's another include 'tgmath.h' but this is
also not available.

Finally I got the build working, but there were some other
inconsistencies which I had to fix. I'll let you all know later (not
today!) about this.

That all said, on this older PC with Win10 and I can see two different
behaviors of the GDI+ branch on my machine:

(1) Switching schemes is similar to what Greg (and Ian?) showed in their
videos. I can see "blocks of widgets" draw slowly in sequence.

(2) Resizing the window is slooooow, but on *my* system it looks as if
the entire screen is drawn almost at once. If I move the mouse while
it's drawn, the window keeps its size (and draws the widgets) and then
"jumps" to its next size (according to the current mouse position).

Behavior (2) is different than Greg's reports, and although it's very
slow the drawing of the entire window seems to happen simultaneously.


OTOH, the "master" build (GDI) works almost smoothly in both scenarios.
There's a tiny flicker when switching schemes but it's almost invisible,
likely due to the older hardware (probably more than 10 years old).


Before anybody asks: no video on available on this machine (unless I use
a camera or my smartphone which I don't plan to do now).

[Greg Ercolano]

On 2/7/21 10:40 AM, Albrecht Schlosser wrote:

On 2/7/21 12:35 AM Greg Ercolano wrote:

     Albrecht, maybe test without the VM, as we can't compare driver behavior that way.

That experiment took almost 7 hours (clock time) for updating my "bare metal" older (Win7 times) PC which is now also running Win10. I had Win 10 "2004" (spring 2020) running with the latest updates in September 2020. I updated to the latest patches only, update "Version 20H2" still TBD.

    Now you know our pain : D
    Yeah, sometimes it takes me a full day or two to get Windows happy on a machine (linux too).
    Of course OSX is never a problem, because the OS vendor also makes the hardware..

OK, my two VS versions on this system are VS 2008 and VS 2010. Unfortunately I couldn't build OOTB, neither master nor Manolo's GDI+ branch. First surprise: these versions (or at least 2010 with its SDK) don't know round() even if 'math.h' is included, hence I had to fix this "manually". The applied hack works but I'm still looking for a better solution...

    Sounds like a good test to use those old versions. I still use VS7 to build my commercial software,
    but I haven't been using that for testing this, though I suppose I should..

[..]

OTOH, the "master" build (GDI) works almost smoothly in both scenarios. There's a tiny flicker when switching schemes but it's almost invisible, likely due to the older hardware (probably more than 10 years old).

    That tiny flicker is likely due to the window for the schemes test not being double-buffered,
    perhaps on purpose to show this kind of problem; it's an Fl_Window subwindow inside an Fl_Double_Window app.
    Not sure actually if that combo is what makes it draw slowly, but it's an interesting metric.

Before anybody asks: no video on available on this machine (unless I use a camera or my smartphone which I don't plan to do now).

    For what it's worth, I shot my videos using linux remote desktop'ed into the windows machine,
    using ffmpeg to do the screen recording, e.g.

        /usr/local/ffmpeg-3.0-64bit-static/ffmpeg -f x11grab -r 10 -s 950x450 -i :0.0+0,100 -vcodec libvpx -b 800k /tmp/output.webm

    ffmpeg's syntax is a bit byzantine; the red is width/height, the green is the x,y offset of the top/left of the recording area,
    and /tmp/output.webm is the resulting video w/out sound. I had to use "-r 10" to get the timing right; larger numbers recorded
    everything in slow motion (which is why I included the clock with a smooth second hand)

    I found that remote desktop gave the same visual results as being in front of the machine itself, otherwise I'd have
    used a local screen recorder on the windows machine. But the less software and dicking around on a Windows machine
    I can do, the better my day generally is, so..

[Albrecht Schlosser]

On 2/7/21 8:01 PM Greg Ercolano wrote:
>
> On 2/7/21 10:40 AM, Albrecht Schlosser wrote:
>> On 2/7/21 12:35 AM Greg Ercolano wrote:
>>>
>>>      Albrecht, maybe test without the VM, as we can't compare driver
>>> behavior that way.
>>
>> That experiment took almost 7 hours (clock time) for updating my "bare
>> metal" older (Win7 times) PC which is now also running Win10. I had
>> Win 10 "2004" (spring 2020) running with the latest updates in
>> September 2020. I updated to the latest patches only, update "Version
>> 20H2" still TBD.
>
>     Now you know our pain : D

Well, I knew that before. But it's always annoying again. And the
circumstances (no updates for ~20 weeks) made it even harder.

>> OK, my two VS versions on this system are VS 2008 and VS 2010.
>> Unfortunately I couldn't build OOTB, neither master nor Manolo's GDI+
>> branch. First surprise: these versions (or at least 2010 with its SDK)
>> don't know round() even if 'math.h' is included, hence I had to fix

>> this "manually"...

>
>     Sounds like a good test to use those old versions. I still use VS7
> to build my commercial software, but I haven't been using that
>     for testing this, though I suppose I should..

Yes, indeed. We should try to build the latest version at least from
time to time on older (build) systems to see if it still builds. If not
we can likely change the code - for instance 'round(x)' can be replaced
with 'int(x+0.5)' which would likely be even faster. And so on...

>> OTOH, the "master" build (GDI) works almost smoothly in both
>> scenarios. There's a tiny flicker when switching schemes but it's
>> almost invisible, likely due to the older hardware (probably more than
>> 10 years old).
>
>     That tiny flicker is likely due to the window for the schemes test

> not being double-buffered, perhaps on purpose ...

I'm not sure this was on purpose, but anyway, it's a good test. Maybe
someone had issues with nested Fl_Double_Window's - I hope not! - we
should maybe test this.

>     to show this kind of problem; it's an Fl_Window
> subwindow inside an Fl_Double_Window app.
>     Not sure actually if that combo is what makes it draw slowly, but
> it's an interesting metric.

AFAICT these two windows are drawn independently from each other. This
interaction could cause additional slowness. We'd definitely need a
single window test app with a lot of text and (gleam and other scheme)
boxes for better test results of GDI vs. GDI+.

>> Before anybody asks: no video on available on this machine (unless I
>> use a camera or my smartphone which I don't plan to do now).
>
>     For what it's worth, I shot my videos using linux remote
> desktop'ed into the windows machine,
>     using ffmpeg to do the screen recording, e.g.
>
> /usr/local/ffmpeg-3.0-64bit-static/ffmpeg -f x11grab -r 10 -s 950x450 -i
> :0.0+0,100 -vcodec libvpx -b 800k /tmp/output.webm
>

>     ffmpeg's syntax is a bit byzantine; ...

Thanks for this ffmpeg example. I found my way to do this on Linux which
is what I used to make the video I posted.

My question regarding this is how you "linux remote desktop'ed into the
windows machine". I'd like to do this as well but I don't know how. This
could help me very much with my tests because the "old PC" is in another
room. Can you give some advice or hints?

>     I found that remote desktop gave the same visual results as being
> in front of the machine itself, otherwise I'd have
>     used a local screen recorder on the windows machine. But the less
> software and dicking around on a Windows machine
>     I can do, the better my day generally is, so..

Yeah, that's exactly my issue. If I could do the tests and development
on that other Windows PC remotely from my Linux notebook that would help
very much.

PS: I know of TeamViewer and I'm using it routinely to help other people
if necessary but I wouldn't want to use it at home because AFAICT all
the communication goes over their servers. I thought of vnc as an
alternative but never started a try.

[Greg Ercolano]

My question regarding this is how you "linux remote desktop'ed into the windows machine". I'd like to do this as well but I don't know how. This could help me very much with my tests because the "old PC" is in another room. Can you give some advice or hints?

    I've been using VNC at both ends; "Tight VNC" server on the windows machine, and TigerVNC on the linux side for the 'vncviewer':

$ rpm -qf /bin/vncviewer
tigervnc-1.8.0-17.el7.x86_64

    Of interest, tigervnc uses FLTK for its dialog prompts : D
    The manager of that project has been on the group a few times in the past.

    I find I can operate my EE/CAD software from my linux workstation over to the Windows7 machine
    efficiently enough to do careful mouse movement placement of circuit board traces and stuff, avoiding
    having to actually sit in front of the Windows box itself, so it's fairly efficient over a gig ether network.

     I found that remote desktop gave the same visual results as being in front of the machine itself, otherwise I'd have
     used a local screen recorder on the windows machine. But the less software and dicking around on a Windows machine
     I can do, the better my day generally is, so..

Yeah, that's exactly my issue. If I could do the tests and development on that other Windows PC remotely from my Linux notebook that would help very much.

    Ya, it's useful for connecting to everything, even Mac.
    I often don't have to use my KVM anymore (except for emergencies that involve a console)

PS: I know of TeamViewer and I'm using it routinely to help other people if necessary but I wouldn't want to use it at home because AFAICT all the communication goes over their servers. I thought of vnc as an alternative but never started a try.

    TeamViewer's more than you need for an internal network, but it works.
    I mainly use it for connecting over the internet to customers.

    I don't like how they switched to a rental licensing scheme.. that's really annoying.

    For personal use TV is "free", but since I also use it for work with customers,
    so I've been stuck on their last version that still uses a 'fixed license' because
    I don't want to be locked into $100's per year, or whatever they switched to lately
    because they got a lot of backlash from users.

[Manolo]

The new GDI+ commit (310fc53) should fix text drawing and fl_text_extents in all situations

where text is drawn.

[Ian MacArthur]

On 9 Feb 2021, at 12:58, Manolo wrote:
>
> The new GDI+ commit (310fc53) should fix text drawing and fl_text_extents in all situations
> where text is drawn.
>

I ran through various tests I tried before, and this seems to be OK, in that things work, and the misaligned words and so forth are sorted.
This was on the Win10 laptop, compiled with mingw32 and 64 builds. Behaviour was “the same” for both toolchains.

Observations:

Text Handling:
The font rendering is broadly OK now, but is visibly different from the “default” text behaviour. On small font sizes, the text looks slightly fuzzy, sort of “out of focus”, in a way that the stock fltk text, and other apps, do not.

Large text looks better, but if I look really closely it is apparent there are slight jaggies on curved parts of characters that are less apparent on the “stock” text handling. Clearly, then, the GDI+ font smoothing is doing something different from what the default text rendering does, and (at least to my eyes) it is not as good.


Scheme Issue:
The slow-redraw problem observed on changing to the gleam or plastic scheme is still present.



Does anyone know anything about Direct2D? I certainly don't, but apparently that’s the preferred mechanism these days, rather than GDI+ because it integrates better with other render methods and is hardware accelerated. It’s apparently what MS use for their own stuff now.
But... the minimum supported version is Win7 (or maybe Vista with service packs.)

[Albrecht Schlosser]

On 2/7/21 9:29 PM Greg Ercolano wrote:
>
>     I've been using VNC at both ends; "Tight VNC" server on the windows
> machine,

Downloaded from tightvnc.com and installed. Works.

However, some commandline switches don't seem to work (I tried to serve
only a port of my two monitor desktop), but finally I used the full desktop.

> and TigerVNC on the linux side for the 'vncviewer':
>
> $ rpm -qf /bin/vncviewer
> tigervnc-1.8.0-17.el7.x86_64

I didn't find a TigerVNC package on my Linux Mint (Ubuntu based), hence
I built TigerVNC myself.

The build using FLTK 1.4 worked with a few tweaks (missing FLTK include
files) but *crashed* after connection as soon as I moved the mouse.
Didn't dig into it...

Building v1.11 (not master) worked fine with FLTK 1.3 and the same added
headers, and it does indeed work in practice.

Great, thank you very much!

PS: I did my latest tests for this FL_MOUSEWHEEL issue in fltk.general
using this VNC config which worked great. Even switching the zoom factor
of one of the two monitors via VNC worked. I'm impressed!

>     Of interest, tigervnc uses FLTK for its dialog prompts : D
>     The manager of that project has been on the group a few times in
> the past.

Yep, I knew, and he recently posted issue #182 (wayland clipboard
problem) which I could fix meanwhile (still need to push the solution to
the 1.4 (master) branch.



PS: Pierre, if you're following this: should I create a PR?


commit 6ac856f0b9de183030c542726dcf96051467a154 (HEAD -> 1.11-branch)
Author: Albrecht Schlosser <albrech...@online.de>
Date: Tue Feb 9 15:39:57 2021 +0100

Include headers required for building with FLTK 1.4

diff --git a/tests/perf/fbperf.cxx b/tests/perf/fbperf.cxx
index a19ee479..661a58dd 100644
--- a/tests/perf/fbperf.cxx
+++ b/tests/perf/fbperf.cxx
@@ -20,6 +20,7 @@
#include <sys/time.h>

#include <FL/Fl.H>
+#include <FL/x.H>
#include <FL/Fl_Window.H>
#include <FL/fl_draw.H>

diff --git a/vncviewer/Viewport.cxx b/vncviewer/Viewport.cxx
index 84777be1..d47e9a9d 100644
--- a/vncviewer/Viewport.cxx
+++ b/vncviewer/Viewport.cxx
@@ -68,6 +68,8 @@

#include "PlatformPixelBuffer.h"

+#include <FL/Fl.H>
+#include <FL/x.H>
#include <FL/fl_draw.H>
#include <FL/fl_ask.H>

[Manolo]

On Tuesday, February 9, 2021 at 6:55:49 PM UTC+1 imacarthur wrote:

I ran through various tests I tried before, and this seems to be OK, in that things work, and the misaligned words and so forth are sorted.
This was on the Win10 laptop, compiled with mingw32 and 64 builds. Behaviour was “the same” for both toolchains.

Observations:

Text Handling:
The font rendering is broadly OK now, but is visibly different from the “default” text behaviour. On small font sizes, the text looks slightly fuzzy, sort of “out of focus”, in a way that the stock fltk text, and other apps, do not.

Large text looks better, but if I look really closely it is apparent there are slight jaggies on curved parts of characters that are less apparent on the “stock” text handling. Clearly, then, the GDI+ font smoothing is doing something different from what the default text rendering does, and (at least to my eyes) it is not as good.

Thanks Ian for your continued testing.
I propose in the git repo  (at 97fdbcd) an attempt to improve text drawing for small font sizes which should be now very crisp.

[MacArthur, Ian (Leonardo, UK)]

> I propose in the git repo  (at 97fdbcd) an attempt to improve text drawing for small font sizes which should be now very crisp.

Hmm, I did a full rebuild and tested.
Basically, it all works, but...

- Schemes "gleam" and "plastic" are still painfully slow on this machine.

- The text is different again, but I hesitate to say better - see attached grab of the rotated_text demo. showing the "stock" and "GDI+" versions.

Basically, large text is pretty well AA in both, though the actual AA applied seems to be different (and the "stock" version looks smoother on this LCD display, FWIW.)

Small text, however, appears to be not AA at all now in the GDI+ case, though that does make it sharper than the previous iteration and it no longer has the "out of focus" look it had. the "stock" small text looks to be AA to some extent and does look smoother overall.

It may be we are hitting the limits of what GDI+ can actually do, and that may be why MS seem to have given up on it?
I really do not know.



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

[Manolo]

After all these tests, I conclude that GDI+ is not convenient for text drawing

and is not useful for drawing horizontal and vertical lines.

New proposal for fellow developers to evaluate:

use GDI+ only when it allows antialiasing beyond what GDI can do.

The modified code is in another branch I called    "GDI+soft"

   git clone https://github.com/ManoloFLTK/fltk.git

   git checkout GDI+soft

   autoconf -f

   ./configure                 <----- not necessary to activate any special option here

   make

CMake-based build works also. Default settings are enough.

GDI+ is initialized when the app starts and is shutdown when it stops.

GDI+ is called at each call of fl_line_style() to change accordingly the GDI+ pen.

GDI+ is called by these drawing functions:

fl_arc(int, int, …)

fl_pie()

fl_line()

fl_loop()

fl_polygon()

fl_circle()

and all functions to draw "complex shapes".
All the rest (text, horizontal and vertical lines, rectangles, boxes, images) is unchanged: GDI is used.

App test/unittests evidences the benefit ot antialiased circles, ellipses and oblique lines,

and test/device that with clock hands and complex shapes.

The plastic and gleam schemes are completely GDI-based, so there's no slowdown

when they are used.

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.

[MacArthur, Ian (Leonardo, UK)]

> The modified code is in another branch I called    "GDI+soft"

> CMake-based build works also. Default settings are enough.

I did not try cmake, but the autoconf build ran cleanly.

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

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

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


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

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

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.

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

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

[Manolo]

Thanks Ian for your testing.

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.

[MacArthur, Ian (Leonardo, UK)]

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…

 

 

 

 

 

 

 

 

[MacArthur, Ian (Leonardo, UK)]

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…

 

See attached - TBH this doesn't really show the full effect - I think the screen capture is only getting "some" of the frames - in "real life" I see a much more "progressive" fill, with each line visible.

 

The double_window version is basically instant; much faster than this.

 

 

 

 

 

[Manolo]

@Ian: In fact, I get the same or very similar drawing duration of the single-window

in my test, which I qualified "a few tenths of a second". It's very perceivable, there's no doubt.

Antialiased oblique lines are also very perceivably better than non antialiased ones.

My point is that the doublewindow test is a very extreme situation by drawing a very large

number of antialised lines.