Xlib backend

[Thiago Milczarek Sayão]

Hi,

Xlib port at:
https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib

Is able to very poorly run Ensemble8:
java @build/run.args -jar apps/samples/Ensemble8/dist/Ensemble8.jar

Keyboard events still do not work, mouse clicks are still buggy.
There will be crashes, but it's progress.
Window size & positioning is better now.

I am painting directly like this:

void WindowContextBase::paint(void* data, jint width, jint height) {
    Pixmap pixmap = XCreatePixmapFromBitmapData(display,
DefaultRootWindow(display), (char *) data, width, height, 0, 0,
depth);
    XCopyPlane(display, pixmap, xwindow, DefaultGC(display,
DefaultScreen(display)), 0, 0, width, height, 0, 0, 1);

    XFlush(display);
    XFreePixmap(display, pixmap);
}

It does flicker a little, maybe it needs XSync extension to draw together
with WM, maybe some kind of buffering.
Using cairo is possible, but it's a final render, not sure if there will be
advantages.

I am accepting opinions.


-- Thiago.

Em ter., 12 de abr. de 2022 às 03:22, <Gregor.Schmid at qfs.de> escreveu:

>
> Hi Thiago,
>
> I wholly agree.
>
> If gtk can be taken out of the equation it will reduce dependencies
> significantly. Like we had with gtk2 vs. 3 in JavaFX/Swing
> cross-embedding. Moving to gtk3 would start this all over again
> whereas plain Xlib should remain fully compatible regardless of the
> gtk version used by Swing (or SWT or whatever).
>
> I'll gladly help with testing - just ping me when you've got a
> version that is reasonably stable.
>
> Best regards,
>     Greg
>
> Thiago Milczarek Sayão <thiago.sayao at gmail.com> writes:
>
> > Kevin,
> >
> > Sure, I was hoping for the question.
> >
> > "The focus of GTK has moved away from being a “meta toolkit” that other
> > toolkits can use as a “backend”."
> >
> > Quoted from
> >
> https://discourse.gnome.org/t/gtk4-migration-window-management-functions-gone/7542/4
> >
> > The first attempt I have made is the logical one, gtk4:
> > https://github.com/openjdk/jfx-sandbox/tree/tsayao_gtk4_playground
> >
> > Then I have discovered it's not possible to use gtk4 without Xlib and
> that
> > many window management functions are gone (see the quotation link).
> > In addition to this:
> > - Gtk4 cannot draw directly on the window or set the background without
> > gtk4 css;
> > - It cannot even move the window, just tell the compositor it started a
> > move.
> >
> > I also have played plenty with gtk3, it breaks a lot of things thru the
> 3.x
> > release cycle, such as DND.
> >
> > So, I see no reason to use Gtk if Xlib fits better as a glass backend
> (has
> > all the needed functions) and Gtk would use Xlib anyway and hide much
> > needed functionality.
> >
> > Current glass Gtk backend already touches a lot of Xlib.
> >
> > Wayland is fully compatible with Xlib, so we can work on "both worlds"
> with
> > it. Someday on the future a pure Wayland backend would be nice.
> >
> > I'm happy to answer any further questions.
> >
> > -- Thiago.
> >
> >
> >
> >
> > Em seg., 11 de abr. de 2022 às 12:41, Kevin Rushforth <
> > kevin.rushforth at oracle.com> escreveu:
> >
> >> Can you say more about the motivation for doing this? Given the eventual
> >> direction for Wayland support, even in X11 compatibility mode, I would
> >> expect more use of gtk and less use of Xlib, not the other way around.
> >>
> >> -- Kevin
> >>
> >> On 4/10/2022 2:43 PM, Thiago Milczarek Sayão wrote:
> >> > Hi,
> >> >
> >> > I got simple samples running on the pure Xlib port of the Gtk backend.
> >> >
> >> > It still has gtk code, but mainly uses Xlib by now. Don't judge the
> code,
> >> > I'm porting it gradually.
> >> >
> >> > https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib
> >> >
> >> > java @build/run.args -cp apps/toys/Hello/dist/Hello.jar
> >> hello.HelloCursors
> >> >
> >> > Window coordinates and sizes are still off a bit, so you might have to
> >> > resize the window to redraw.
> >> >
> >> > -- Thiago.
> >>
> >>
>
> --
> Gregor Schmid
>
> E: gregor.schmid at qfs.de
> T: +49 8171 38648-11
> F: +49 8171 38648-16
>
> Quality First Software GmbH | www.qfs.de
> Bürgermeister-Graf-Ring 10 | 82538 Geretsried | Germany
> GF Gregor Schmid, Karlheinz Kellerer
> HRB München 140833
>
> The data protection information in accordance with the EU General Data
> Protection Regulation applies to authorized representatives /
> authorized representatives of "legal persons" in accordance with Art.
> 12 ff. DS-GVO
> https://www.qfs.de/fileadmin/Webdata/pdf/en/dsgvo.pdf
>