Comment by ~eliasnaur on ~eliasnaur/gio
On Wed Oct 16, 2019 at 5:29 PM ~db47h wrote:
Yes, eglSwapInterval should be used on X11, but since context.Present() calls it already, I was hoping for a notification that the function has returned. On the other hand, one cannot rely on vsync on X11 since it's not always working, especially on optimus laptops.
It's possible we're talking past each other. Yes, eglSwapBuffers is called by Present, but eglSwapInterval(1) for enabling v-sync (as far as the driver allows), is currently called on Windows only.
There is an implicit notification that eglSwapBuffers completed: the gpu.Flush call waits for the result of the previous frame before returning, which includes the buffer swap. The separate Flush is necessary to give the main goroutine a chance to work concurrently with the GPU goroutine.
On Wayland eglSwapInterval is 0, but the frame rate is throttled by wayland frame callbacks instead, as per
https://emersion.fr/blog/2018/wayland-rendering-loop/Here's where I'm coming from: https://web.archive.org/web/20190506122532/http://gafferong ames.com/post/fixyourtimestep/
In the main loop, I usually wait for events if there is no animation going on, and just poll events if there is any animation. The only thing that is expected from the platform driver is a PollEvent() and an abortable WaitForEvent(). All this with vsync enabled: no tearing and no erratic frame rate.
It's entirely possible the animation protocol between app.Window and the native peer could be improved. I'm open to alternative designs.
Also, since one can never be sure that vsync works, I throw in a frame throttling mechanism, just not to kill the CPU while doing nothing (then rely on gl.Flush and hope for the best tearing-wise).
SGTM.
-- elias
Comment by ~eliasnaur on ~eliasnaur/gio
On Wed Oct 16, 2019 at 4:07 PM ~db47h wrote:
Basic animation added : https://github.com/db47h/gio/tree/x11_v2
It is in a usable state, so please give it a go.
I said
basicanimation because right now the event loop is throttled to draw at a fixed 1/60s interval while animating. While this helps limit CPU usage from the app itself, oddly enough Gnome Shell shows 80% CPU usage...Is there any way to get feedback from eglDriver.Present() (i.e. vsync), or some other timer in gio in order to throttle the event loop? Well, I know that hoping for a reliable vsync is a pipe dream on X11, but a ticker from gio would be awesome.
There is eglSwapInterval. See the comment in egl.go:
// eglSwapInterval 1 leads to erratic frame rates and unnecessary blocking. // We rely on platform specific frame rate limiting instead, except on Windows // where eglSwapInterval is all there is. if runtime.GOOS != "windows" { eglSwapInterval(eglCtx.disp, 0) } else { eglSwapInterval(eglCtx.disp, 1) }I suppose eglSwapInterval should be used on X11 as well.
Comment by ~eliasnaur on ~eliasnaur/gio
On Tue Oct 15, 2019 at 1:50 PM ~db47h wrote:
Keyboard support added: https://github.com/db47h/gio/commit/f6458e67809b b39985cc9526be35aff6b7595798
Nice.
I didn't use XKB and went for XIM. A few things worth noting:
- CTRL-SHIFT-U
?
- unicode code point works, however the helper
windowshowing what code point you enter appears at the bottom left of the GIO window. If anyone has a clue on how to move it or better show it inline in a text editor, that would be awesome.This is not something the Editor supports today.
Gio needs better support for IMs for the mobile platforms, at which point I suspect the OS would like to know the window coordinates of the caret.
Plus it shouldn't be available unless actively editing something.
Gio calls ShowTextInput(visible) on the native window to guide the soft keyboards on the mobiles. Perhaps that is also useful to show and hide the XIM window.
Comment by ~eliasnaur on ~eliasnaur/gio
On Mon Oct 14, 2019 at 11:34 PM Uti Michael wrote:
You mean users can actually create custom button widgets?, seems I have to create custom layouts and there are unexportable functions like rrect and fill functions. Also are IconButtons only circular?
My suggestion was to send a patch that expanded the text button to optionally draw an icon.
However, since all of Gio is UNLICENSEd, you can also freely copy the necessary code and draw the icon button yourself.
-- elias
Comment by ~eliasnaur on ~eliasnaur/gio
On Mon Oct 14, 2019 at 12:23 AM Uti Michael wrote:
Hello, really don’t know if there’s a way to have buttons with text and icons?
There is a button with text, and there is a button with an icon, but not one with both. I imagine it would be relatively straightforward to add icon support to the text variant.
-- elias
Comment by ~eliasnaur on ~eliasnaur/gio
On Sat Oct 12, 2019 at 12:54 PM ~db47h wrote:
Updated with EGL stuff moved where it belongs. Sorry, I did a force push after rebasing on master with the xkb changes so your comments are gone.
Anyhow, about using an array for drivers in https://github.com/ db47h/gio/commit/1c5614b4ed63104f8f98b0ad3eff50312a3b39f6#diff-70a2c89ac 82cfe06c897443a159d0563 : I thought about it, but for only two linux specific drivers, I believe it would be a bad case of over engineering (need to set-up some self-registering mechanism with a mutex and a priority system).
I don't think you need a mutex, since the drivers are registered in init functions that run in a single goroutine.
You're right about priorities, however. Go probably runs init functions within a package in a particular order, but that's too subtle to rely on.
Comment by ~eliasnaur on ~eliasnaur/gio
On Fri Oct 11, 2019 at 1:15 PM ~db47h wrote:
Since @dennwc looks busy, I took the liberty to go ahead and integrate his work on top of latest master: https://github.com/db47h/gio/commits/x11 (still without keyboard support).
Great!
The first two commits are pretty straight forward: decalre a windowDriver interface, make newContext a window method in order to prevent conflicts between eglDriver/windowDriver, and remove refs to the wayland-only
connvariable in the xkb driver.X11 support proper is a straight copy-paste of ~dennwc's os_x11.go. I just added the few bits and pieces to have the default linux builds to provide dual wayland/x11 support and optionally disabling them with a nowayland or nox11 tag.
If this looks good to everyone, I'd like to go ahead and add keyboard support.
Looks good to me; I left a few comments on GitHub. I also took the liberty of integrating your xkb fix.
Comment by ~eliasnaur on ~eliasnaur/gio
On Thu Oct 10, 2019 at 1:36 PM ~db47h wrote:
Your point is still valid, however. A less radical solution is a nowayland tag for building without Wayland support.
fair enough. Looking at the current implementation, I'm wondering why Window.driver is not an actual interface: there's a check that the window type implements a non-declared driver interface, so why not declare it as such? It would make implementing the wayland and x11 drivers (with optional support for the other) much easier.
FWIW, I believe ~dennwc's work incomplete patch promotes the anonymous interface to a named type.
I tend to avoid interfaces I don't need, and Gio didn't need multiple drivers in one build before X11.
Comment by ~eliasnaur on ~eliasnaur/gio
On Wed Oct 9, 2019 at 4:11 PM ~db47h wrote:
While dynamic fallback from Wayland to X11 would be a nice feature, it requires the executable to dynamically link with libwayland-egl.so and a couple others (unless we start to do ugly things like dl'open/GetProcAddress). I'm not sure that this is desirable for X11 builds.
I suspect many systems have libwayland-egl.so installed even though the user runs X11.
Your point is still valid, however. A less radical solution is a
nowaylandtag for building without Wayland support.