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.
---
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!
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?
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.
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.
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
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.
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.
(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.
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.
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):
<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.
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.
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..
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..
"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.
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. ;)
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.
With git commit 2633e5b, you should have something that can both draw small fontswithout moving some words up and down, and compute fl_text_extents correctly.
Yes, unittests now working again with text rendering:
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.
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.
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...
[..]
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..
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.
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.
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...
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…
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.