Xlib backend

[Thiago Milczarek Sayão]

Hi,

Did some progress on the xlib backend.

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

- Transparent Stages
java @build/run.args -cp apps/toys/Hello/dist/Hello.jar
hello.HelloTranspStageAnim

- On top stages
java @build/run.args -cp apps/toys/Hello/dist/Hello.jar
hello.HelloStageOnTop

gtk is not initialized anymore (still links because there is porting to do).

-- Thiago.

Em ter., 17 de mai. de 2022 às 18:17, Thiago Milczarek Sayão <
thiago.sayao at gmail.com> escreveu:

> Hi,
>
> Did some improvements on my "pure x11" branch:
>
> - Bitmaps are now handled by cairo which will use Xrender if available
> (will be beneficial if there's an alpha channel).
> - Configuration using Xsettings (such as double click time)
> - Setting the app icon now works
> - Custom cursor works
> - Mouse button works
> - Able to launch Ensemble8 (with random crashes).
>
> Interesting thing is that there's no need to convert BGRA -> RGBA. Not
> sure if it's a big performance improvement.
>
> It seems the only thing that will be missing to completely ditch gtk are
> the "common dialogs" such as file open, etc.
>
> I'm also investigating Wayland. It's somewhat similar to Xorg when it
> comes to events and the use of XDG specs. Probably will replace cairo with
> egl.
>
> -- Thiago.
>
>
>
>
>
>
>
>
>
> Em dom., 24 de abr. de 2022 às 17:40, Thiago Milczarek Sayão <
> thiago.sayao at gmail.com> escreveu:
>
>> 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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220617/d60279ff/attachment-0001.htm>