Add experimental GDK GUI backend#2782
Conversation
|
I'd be happier to see a move away from GDraw than a patch to make it easier to continue using GDraw, but this is impressive work and if it makes the package play better with desktop environments, it's a good thing. |
|
IMO, the only option of moving away from GDraw would be to move to Qt. Now I've had time to see it, I hate GTK (in particular GTK3). In any case, that would be a major undertaking, far greater than this patch would ever be. |
21f2637 to
a88bfeb
Compare
bac1216 to
f084bc9
Compare
|
Here's a GDK2 build for Windows: https://ci.appveyor.com/project/fontforge/fontforge/build/1.0.111/artifacts (I set it to GDK2 because I normally build GDK3 and I want to ensure it still builds on GDK2) Some noted differences between GDK2 and GDK3:
Known issues remaining:
|
|
Uh. So I noticed a slow-down when you zoomed in too far on a glyph - see here. I had fixed a bug where a path that was indicated as to be drawn with a dashed line was not actually drawn as such (see here). So old FF was mistakenly drawing a solid line while I was drawing a dashed line. It turns out if you zoom in too far on a dashed line, Cairo runs slow. So... does anyone know what the dashed vs solid line is meant to mean?
|
98f9b4a to
eb14574
Compare
|
@jtanx I can arrange testing on Win and Mac on a daily workflow if you require. |
|
@jtanx this is awesome work!! |
|
gnulib is broken again. |
|
@jtanx wrote,
That's odd. I thought it was meant to be solid, not dashed. |
…sible _GWidget_TopLevel_eh will return without processing if GDrawNativeWindowExists returns false. This means that under the old code, for windows containing child windows that are only properly sized by GWidgetFlowGadgets, this will only happen when the window becomes visible and when a configure message is received after that. By removing the visibility check from GGDKDRawNativeWindowExists, we allow the configure events to get send and this means that the window can be properly sized before it becomes visible. The second change in this commit is to filter out et_resize messages that are only the result of moving. They are unnecessary (if any parts need to be redrawn due to a move, an expose message will/should be sent). Furthermore, on Windows in particular, it causes excessive CPU usage because repeated move messages are sent as the window is moved around - in comparison to Linux/X11 which only sends one at the end of the move, or even OS X, which compresses the sizing events.
I cannot specify wam_noresize on the tools window because under KDE it plays up
My code is under the 2-clause BSD license. GWW's code in ggdkcdraw.c remains under the original license he used.
I did this before? I must have lost it with the force.
from exposed areas. I really hope this works.
Ugh this is getting messy.
It causes a notable performance hit e.g. for the ruler tool Also: Try to minimise expose/raise calls within cvuler itself
Is this for hi-dpi auto detection? You may want to use |
|
I just tried this on Linux and it is working on hi-dpi screen without any manual settings: |
|
Any updates here? Since this keeps the default X backend essentially unchanged, I think it should be merged and further work on GDK backend can be continued (potentially allowing others to contribute). |
|
Sorry about the delay, yeah I'm fairly happy to merge it (any objections, @frank-trampe?); it more or less works. I got busier, and then I saw the breaking changes coming in GDK4. That coupled with debating what version of GDK to support, or if this would have been possible/better done at the GTK level, and I kind of got put off by making any further changes. I'll see if I can clean it up a little before merging though. |
|
I think GTK3/GDK3 will be around for some time and the API is now stabilized, so that is a win. GTK3 was first released in 2011 and GTK2 is still a thing today. Doing this work with GTK instead of GDK is something to explore indeed, but I think it would be easier to do on top of this work. |
|
Agree with Khaled on all points
On Mar 10, 2018 10:10 AM, "Khaled Hosny" <notifications@github.com> wrote:
I think GTK3/GDK3 will be around for some time and the API is now
stabilized, so that is a win. GTK3 was first released in 2011 and GTK2 is
still a thing today.
Doing this work with GTK instead of GDK is something to explore indeed, but
I think it would be easier to do on top of this work.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2782 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAP9y4t1VoXxME0ns6nyfTQ9JR3XT8wzks5tc5iXgaJpZM4Jqfx3>
.
|
|
Thanks a lot for this PR! 😍
What works on Wayland:
What doesn't work:
Looks like the drawing areas are not refreshed. I'd love to help debugging! Should I open a new issue? |
|
Thanks for testing! Yeah sure, feel free to create issues for anything you find. |
For historical reasons, Mac OS X uses 72 DPI for the base 1x resolution. |
Add experimental GDK GUI backend
Note: Not to be merged as of yet.
This adds an experimental GDK backend to GDraw. It is meant to be more or less a drop-in replacement for the X11 backend. This backend is enabled by passing
--enable-gdkat the configure stage. This will add a dependency onlibgdk-3.0orlibgdk-2.0(provided bylibgtk-3-devandlibgtk2.0-devor equivalent respectively) - it will preferlibgdk-3.0tolibgdk-2.0, but either should work. If you wish, you may force it to explicitly build with either GDK2 or GDK3 by passing--enable-gdk=gdk2or--enable-gdk=gdk3.Motivation and Context
By using the GDK backend, it removes the hard dependency on X11. This is beneficial on Windows and OS X as it removes the need to run an X server (VcXsrv or XQuartz). Note that most of the benefits of this backend would be on Windows.
Side-effects of using GDK:
Technically the GUI can now also be built on Homebrew using this backend (#2668), although I don't have enough experience with the OS X packaging.
Caveats
Expect this backend to crash a bit more than on X11. I have been testing quite a lot, but it's difficult to emulate the behaviour of that backend exactly. There may be differences in behaviour that I may have overlooked which causes odd things to happen.
Types of changes
Changes to FontForge outside of adding this backend have been kept as minimal as possible. However, some changes did have to be made:
DrawArcfunction in Cairo for the X11 backend.Known remaining issues
startui.cis in particularly bad shape. I remember Command-line processing and "main program" #1277. What I do know is that it has a separate event loop to Windows and Linux, which seems odd.