Re: Should I port my custom UI toolkit to Wayland or GTK/QT?

[Brad Robinson]

Hi Dorota,

Thanks for the info... I wasn't aware of that text input protocol, that
sounds very promising - hopefully they make good progress with that.

Brad

On Sat, Oct 30, 2021 at 7:24 PM Dorota Czaplejewicz <
dorota.czaplejew...@puri.sm> wrote:

> Hi Brad,
>
> On Sat, 30 Oct 2021 10:58:59 +1100
> Brad Robinson  wrote:
>
> > 2. Are there options for IME and Accessibility for pure Wayland apps?
>
> Yes, there are at least 2 approaches:
>
> - embed the IME in your application, like GNOME/Mutter seems to be doing
> (I'm not super acquainted with that)
> - use the text-input and related protocols. They are still far from
> perfect or complete, but they have some momentum.
>
>
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/wip/text-input-next
> (also see the countless issues and merge requests in the same repo).
>
> Cheers,
> Dorota
>

Re: Should I port my custom UI toolkit to Wayland or GTK/QT?

[Brad Robinson]

Hi Igor,

Thanks for taking the time to answer.

It sounds like you're suggesting porting the application to a new toolkit
rather than updating the toolkit?  As mentioned, that's not really feasible
as I have literally hundreds of screens that would need to be ported.
Porting my existing toolkit - either directly to X11, Wayland or by
leveraging an existing toolkit seems an easier option.

Would you say the same about AvaloniaUI... that instead of porting
Avalonia, every app that uses it should move to a new toolkit?

Brad

On Sat, Oct 30, 2021 at 3:07 PM Igor Korot  wrote:

> Hi,
>
> On Fri, Oct 29, 2021 at 6:59 PM Brad Robinson
>  wrote:
> >
> > Hey All,
> >
> > I have a custom UI toolkit that I initially developed for my music
> application over 15 years ago.  Currently it runs on Windows and OSX, and
> I'd like to port it to Linux.
> >
> > The main thing I'm trying to decide is whether to port directly to
> Wayland or to a higher level UI toolkit like GTK or QT.  Here's what I'm
> thinking about.
>
> There is no doubt that the UI should be ported to GTK/Qt/wxWidgets.
>
> Why do you even ask?
>
> Especially since those libraries are capable of being used under both
> X11 and Wayland.
>
> But that not even the main reason.
>
> Wayland/X11 is a low-level API where UI doesn't have any business
> accessing.
>
> There is a reason Qt/GTK/wxWidgets libraries exist - to make the
> cross-platform development
> nice and smooth. Remember the paradigm: design once - build/run everywhere.
>
> Everything else should be irrelevant.
>
> Thank you.
>
> P.S.: If you do port to wxWidgets you could disregard the Windows/Mac
> ports. You will have one
> codebase which will run on all platforms.
>
> P.S.S.: Same can be sad for Qt.
>
> >
> > Pros:
> >
> > * I really like the elegance of Wayland and think I'd enjoy coding
> against it. It seems lightweight and the way of the future for Linux
> desktop apps.
> > * I've written a partial, proof of concept C# wrapper for Wayland which
> seems to work fine. (my toolkit is written in C#)
> > * My toolkit already includes implementations of every control/widget I
> need (including menus) so I don't need much of what GTK/QT provides.
> Wayland seems like a nice fit in this regard.
> > * Regarding GTK/QT I'm not keen to learn yet another UI API unless I
> really have to.  I've dabbled with GTK and didn't really like it. I've
> never used QT but it seems over the top for my needs and possibly difficult
> to call from C#. Wayland seems simple in comparison.
> > * I use Skia for graphics rendering. So long as I can blit to the screen
> and get user input it should port reasonably well.
> >
> > Cons:
> >
> > * Seems like I might need to implement window decorations myself as I
> understand not all Wayland compositors provide this.
> > * System dialogs - in particular file and folder selection dialogs.  I'd
> need to either implement these myself or figure out how to invoke GTK/QT
> versions?
> > * IME support - I believe this is outside the scope of Wayland.
> > * Automation/Accessibility - again outside the scope of Wayland.
> > * OS theme consistency.
> >
> > I think all the cons are workable - either I'm happy to put in the work
> to get it done (cons 1 and 2) or I can live without if I have to (cons 3
> and 4), or I'm not that fussed about (con 5)
> >
> > Other notes:
> >
> > * Porting my apps from my toolkit to GTK or QT is out of the question as
> that would entail porting literally hundreds of screens, dialogs and
> widgets.
> > * I'm a long time Windows developer but I've never done Linux desktop
> development.
> > * I'm not the only one in this boat.  The AvaloniaUI project is very
> similar to my toolkit and while I can't speak for them, they currently use
> X11 and I believe will have similar issues when it comes to Wayland,
> Accessibility and IME.
> > * I'd also really like support for OpenGL.  Not a deal breaker but I
> presume it's available through Wayland.
> > * My toolkit is closed source and only used by apps I develop - it's not
> likely that it will suddenly have lots of additional requirements placed on
> it besides what I'm currently considering.
> > * I don't have any particular distros that I need to support.  If my app
> only works on particular distros then so be it.
> > * It's not urgent and I'm willing to put in the time.
> >
> > So, with all that in mind, here's my questions:
> >
> > 1. Wayland, GTK or QT?
> > 2. Are there options for IME and Accessibility for pure Wayland apps?
> > 3. Assuming I go with Wayland, is there a Linux distro you would
> recommend that includes a good, regularly updated, feature rich Wayland
> compositor. (Unless there's a compelling reason to, I'd prefer not to have
> to compile a compositor myself).
> > 4. Any other advice - am I neglecting to consider anything obvious?
> >
> > Sorry for the long post... much to think about and any advice greatly
> appreciated.
> >
> > Brad
> >
>

Should I port my custom UI toolkit to Wayland or GTK/QT?

[Brad Robinson]

Hey All,

I have a custom UI toolkit that I initially developed for my music
application over 15 years ago.  Currently it runs on Windows and OSX, and
I'd like to port it to Linux.

The main thing I'm trying to decide is whether to port directly to Wayland
or to a higher level UI toolkit like GTK or QT.  Here's what I'm thinking
about.

Pros:

* I really like the elegance of Wayland and think I'd enjoy coding against
it. It seems lightweight and the way of the future for Linux desktop apps.
* I've written a partial, proof of concept C# wrapper for Wayland which
seems to work fine. (my toolkit is written in C#)
* My toolkit already includes implementations of every control/widget I
need (including menus) so I don't need much of what GTK/QT provides.
Wayland seems like a nice fit in this regard.
* Regarding GTK/QT I'm not keen to learn yet another UI API unless I really
have to.  I've dabbled with GTK and didn't really like it. I've never used
QT but it seems over the top for my needs and possibly difficult to call
from C#. Wayland seems simple in comparison.
* I use Skia for graphics rendering. So long as I can blit to the screen
and get user input it should port reasonably well.

Cons:

* Seems like I might need to implement window decorations myself as I
understand not all Wayland compositors provide this.
* System dialogs - in particular file and folder selection dialogs.  I'd
need to either implement these myself or figure out how to invoke GTK/QT
versions?
* IME support - I believe this is outside the scope of Wayland.
* Automation/Accessibility - again outside the scope of Wayland.
* OS theme consistency.

I think all the cons are workable - either I'm happy to put in the work to
get it done (cons 1 and 2) or I can live without if I have to (cons 3 and
4), or I'm not that fussed about (con 5)

Other notes:

* Porting my apps from my toolkit to GTK or QT is out of the question as
that would entail porting literally hundreds of screens, dialogs and
widgets.
* I'm a long time Windows developer but I've never done Linux desktop
development.
* I'm not the only one in this boat.  The AvaloniaUI project is very
similar to my toolkit and while I can't speak for them, they currently use
X11 and I believe will have similar issues when it comes to Wayland,
Accessibility and IME.
* I'd also really like support for OpenGL.  Not a deal breaker but I
presume it's available through Wayland.
* My toolkit is closed source and only used by apps I develop - it's not
likely that it will suddenly have lots of additional requirements placed on
it besides what I'm currently considering.
* I don't have any particular distros that I need to support.  If my app
only works on particular distros then so be it.
* It's not urgent and I'm willing to put in the time.

So, with all that in mind, here's my questions:

1. Wayland, GTK or QT?
2. Are there options for IME and Accessibility for pure Wayland apps?
3. Assuming I go with Wayland, is there a Linux distro you would recommend
that includes a good, regularly updated, feature rich Wayland compositor.
(Unless there's a compelling reason to, I'd prefer not to have to compile a
compositor myself).
4. Any other advice - am I neglecting to consider anything obvious?

Sorry for the long post... much to think about and any advice greatly
appreciated.

Brad

Re: Current state of Window Decorations

[Brad Robinson]

Thanks Simon/Pekka,

As a toolkit developer coming from Windows/OSX this is fairly shocking.
I'm aware of the decoration protocol, but given it's not supported (and by
the sound of it never will be) on some of the major distros makes it almost
worthless.

Seems odd to offload this responsibility to every toolkit without providing
a mechanism to achieve any consistency.  Or... is this just my background
in Windows/OSX where consistency in these areas is really encouraged and
this just isn't expected on Linux?

That said, what would be the recommended way to implement this - would you
typically have one surface for the decorations and an embedded sub-surface
for the content area?  eg: what happens if you use a drawing library
(cairo/skia whatever) for the decorations but then want to embed opengl
content for example.

Brad

On Thu, Jun 25, 2020 at 6:25 PM Pekka Paalanen  wrote:

> On Thu, 25 Jun 2020 11:57:42 +1000
> Brad Robinson  wrote:
>
> > Hey All,
> >
> > What's the current state and/or plans for window decorations with
> Wayland?
> >
> > I just stumbled on this post
> > <
> https://blog.martin-graesslin.com/blog/2018/01/server-side-decorations-and-wayland/
> >,
> > and after reading the comments I've got to say I'm quite shocked that
> > getting a window to appear on screen with title bars and decorations that
> > match the rest of the OS appears to be a non-trivial task.
> >
> > Am I missing something? Have things changed since that post was written?
>
> Hi,
>
> I don't think you're missing much.
>
> Without specific Wayland extensions saying otherwise, clients either
> decorate themselves or live without decorations. I believe the state of
> the art is:
>
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/master/unstable/xdg-decoration
>
> I wouldn't say that the fact that Wayland extensions exist for
> server-side decorations means that a Wayland client would be right to
> not implement client-side decorations. Any compositor likely does not
> implement all the extensions ever defined or even in wayland-protocols
> repository, so clients should have fallbacks. However, it is up to you
> as a developer to decide which fallbacks you implement and which you do
> not. Obviously that will affect your user experience on compositors
> where the fallback would be necessary but you didn't implement it.
>
> Unfortunately we don't have the wayland-protocols adoption website up
> yet, where you could see which compositors and toolkits support which
> extensions. Weston does not support the extension, but I would assume
> some other compositors do.
>
> There are good justifications for both client-side and server-side
> decorations. Which one is better depends on your goals and policies,
> and what you value more, which is why the question raises so much heat
> that few people like to talk about it much as it nearly always
> escalates to a flame war when more people join the discussion.
>
> For example, for some, "match the rest of the OS" is a non-goal, and
> making the app itself look consistent is a goal. For others, it's the
> opposite. Will the application always look and feel the same no matter
> in what environment you run it in, or should it change itself according
> to the environment. How do you make the user feel at home? There is a
> lot more to it than just decorations.
>
>
> Thanks,
> pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Current state of Window Decorations

[Brad Robinson]

Hey All,

What's the current state and/or plans for window decorations with Wayland?

I just stumbled on this post
,
and after reading the comments I've got to say I'm quite shocked that
getting a window to appear on screen with title bars and decorations that
match the rest of the OS appears to be a non-trivial task.

Am I missing something? Have things changed since that post was written?

Brad
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Best practices for client side buffer management

[Brad Robinson]

Hi Pekka,

The problem is, the compositor might not release the buffer until
> you have already submitted a new one.
>

OK... good to know that approach won't work.

I guess what I'm trying to figure out (and probably won't solve completely
till I actually sit down and code it) is how to avoid the software
rendering part of it as much as possible.  My app can have a complex and
deep tree of UI elements so I think it's worth trying to avoid additional
render calls into that tree as much as possible - or at least clip it down
to just the dirty rectangles.  But this requires the rest of the current
buffer be kept up to date.  Presumably if there's a cycle of buffers being
used this would mean either re-rendering certain UI  elements multiple
times, or copying dirty rectangles from previously rendered frame buffers
to the one about to be updated.

I'm not sure if this is a valid or even useful question but: once I've
submitted a buffer to the compositor can I assume the previously submitted
buffer will be returned imminently?

The rest of this discussion got a bit beyond me (although I will need to
support OpenGL eventually).

Thanks everyone for insights... much appreciated.

Brad

>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Best practices for client side buffer management

[Brad Robinson]

Hi All,

@Guillermo: yep, that's exactly the same problem I'm thinking about.

I had an idea that I'm wondering about  the rendering model in my
toolkit is essentially the same as Windows/OSX - where the application
invalidates part of the window, and then at some later point the OS calls
back with a message prompting the app to paint that part of the screen.
ie: multiple invalidate calls are coalesced into a single paint call at a
later time - typically just before entering the message loop's idle state.

Could a Wayland app mimic this behaviour by having a single background
buffer that contains the current window content?  When the application
invalidates the window it does one of two things depending on whether the
buffer has been returned from the compositor yet.

* If the buffer has been returned and no longer in use by the compositor,
it queues a paint message to itself.

* If the buffer hasn't been returned and is still in use by the compositor,
set a flag on the window.  When the buffer is returned from the compositor,
it checks that flag and if set then it clears the flag and queues the paint
message.

The paint message redraws all the invalidated (damaged) rectangles and
re-submits it to the compositor and the whole cycle starts again.

Obviously there's more logic around maintaining the dirty region,
coalescing multiple invalidate/damage calls, an assumption that there's a
mechanism to post a message via the message loop etc... but I hope this
explains the idea.

Would this work?  I think the main requirement would be that:

1. the compositor doesn't change the contents of the buffer and that when
it's returned it's still got the old content.
2. that the compositor returns buffers it's finished with in a timely manner

It's not clear to me from what I've read that either of these points are
true or safe assumptions.

This would eliminate the need to manage multiple buffers, multiple dirty
regions, the need to copy previously rendered content between buffers and
fits nicely with the rendering model of Windows/OSX giving similar
semantics on all platforms.

Brad

On Wed, Jun 24, 2020 at 6:11 PM Guillermo Rodriguez Garcia <
guille.rodrig...@gmail.com> wrote:

> Hi Brad,
>
> El vie., 19 jun. 2020 a las 5:24, Brad Robinson
> () escribió:
> [...]
> >
> > Finally, the toolkit already maintains an off-screen buffer with the
> window's current contents rendered into it.  I'll probably replace that
> with a Wayland buffer, but wondering about partial updates.  eg: if the
> client only needs to redraw a part of the window what's the correct process
> to update just that part with Wayland.  Can I just update the existing
> buffer and prompt Wayland to just redraw that part?
>
> I am facing a similar situation with a toolkit that maintains an
> off-screen buffer with the current window contents, and will update
> that buffer at arbitrary times, when the application needs to update
> the UI.
>
> You must consider the following:
>
> Once you submit a buffer to Wayland you cannot touch it anymore until
> the compositor releases it back (wl_buffer.release callback). From
> Pekka's email:
>
> > When you submit a buffer to a Wayland compositor, it gives the
> > compositor permission to read the buffer at any time, as many times as
> > it wants to, until it tells you with wl_buffer.release that it will not
> > be looking at that buffer again. You must not write to a buffer that
> > might be read by the compositor, as that can cause misrendering on
> > screen (e.g. your repaint is shown unfinished).
>
> This means you cannot simply use the same off-screen buffer that the
> toolkit maintains, since the toolkit should not update the buffer once
> it submits it to Wayland.
>
> At some point I thought that I could have separate Wayland buffers and
> copy damaged regions from the toolkit buffer to one of these Wayland
> buffers before submitting it to the compositor.
> The idea would be to copy the set of regions that were damaged since
> the last update.
>
> But just copying damaged regions is not enough either. From Pekka's email:
>
> > Also, every buffer you submit must be fully drawn, also outside of the
> > areas you mark as damage. The compositor may be reading more than just
> > the damage you submit.
>
> So this means that everytime the toolkit updates the off-screen
> buffer, I may need to copy _the entire thing_ to a Wayland buffer and
> submit it to the compositor... not very efficient I guess.
>
> I have the feeling that Wayland is designed for a model where the
> client renders the entire frame on demand (most of the examples I've
> found so far work like this) and not for a model where the client is
> updating a buffer asynchronously and you just wa

Re: Best practices for client side buffer management

[Brad Robinson]

Hi Pekka,

Thanks for the detailed insight.  That's exactly the kind of info I was
after about how to manage some of this stuff.  I still haven't had a chance
to dig into this in any detail but hope to in the next day or so...

Brad


On Mon, Jun 22, 2020 at 6:46 PM Pekka Paalanen  wrote:

> On Fri, 19 Jun 2020 11:21:34 +0100
> Carsten Haitzler (The Rasterman)  wrote:
>
> > On Fri, 19 Jun 2020 13:24:12 +1000 Brad Robinson <
> brobin...@toptensoftware.com>
> > said:
> >
> > > Hi All,
> > >
> > > I'm fairly new to Wayland and Linux GUI programming in general, but
> doing
> > > some experiments to figure out how to integrate it into my custom UI
> > > toolkit library and have a couple of questions about client side buffer
> > > management.
> > >
> > > Firstly, this is how I'm allocating the backing memory for client side
> > > buffer pools.  This is C# p-invoking to libc, and basically it's using
> > > mkstemp() to get a temp file, ftruncate() to set its length, mmap() to
> map
> > > it and then unlink() once mapped so temp files aren't left behind.  Any
> > > issues with this approach?
> > >
> > > // Get temp file
> > > var sb = new
> > > StringBuilder(System.IO.Path.Join(System.IO.Path.GetTempPath(),
> > > "mmXX"));
> > > int fd = mkstemp(sb);
> > > ftruncate(fd, (ulong)capacity);
> >
> > i assume GetTempPath() will be looking at /tmp ... and /tmp may not be a
> > ramdisk. it may be a real disk... in which case your buffers may be
> getting
> > written to an actual disk. don't use /tmp.
>
> Hi,
>
> that's true. The trick we have been using is create the file in
> $XDG_RUNTIME_DIR which is practically always a tmpfs, but OTOH it might
> not be the best place to store large pixel buffers.
>
> > you might wan to to loop at shm_open or memfd
>
> Right.
>
> > or libdrm for specific drivr
> > allocation calls like drm_intel_bo_alloc_tiled, drm_intel_bo_map/unmap
> etc. the
>
> No, please do not do that!
>
> That will make your program specific to a certain hardware driver,
> which makes it specific to that hardware. Plus, you will have to learn how
> to program specifically for that driver. It's not worth it.
>
> The wl_shm Wayland interface is for software rendering anyway. No-one
> expects a wl_shm-based buffer to be directly usable by a display or a
> GPU driver, it will always be copied by a compositor. So trying to
> shove "hardware buffers" through wl_shm is only picking the worst of
> all options, as direct CPU access to them is often sub-optimal, perhaps
> even prohibitively slow.
>
> > latter libdrm ones wo9uld allow your buffers to possibly be scanned out
> > directly to the screen or used as textures directly without copies, but
> will
> > need careful handling, so do this only as an advanced step.
>
> If you want to use hardware acceleration or allow direct scanout, use
> the proper APIs intended for them: GBM, EGL, Vulkan; if you need to
> pass hardware buffers manually through Wayland, use zwp_linux_dmabuf_v1
> extension instead of wl_shm.
>
> >
> > > // Map it
> > > var addr = mmap(IntPtr.Zero, (ulong)capacity, Prot.Read |
> > > Prot.Write, Map.Shared, fd, 0);
> > >
> > > // Unlink it (so temp files not left behind)
> > > unlink(sb.ToString());
> > >
> > > Secondly I'm wondering about practical strategies for managing client
> side
> > > buffers.  The toolkit in question basically needs arbitrarily sized
> buffers
> > > to render whatever size the window happens to be.  Seems like to use a
> > > buffer pool for this would require some sort of heap manager to manage
> > > what's in each pool.  I'm wondering if there's any recommendations or
> best
> > > practices for how to deal with this.  eg: create one big pool and
> > > explicitly manage what's in there as a heap, use lots of little pools
> with
> > > one buffer in each, a combination of both, something else?
> >
> > resizes of windows are less common (in general) than rendering to them.
> here
> > i'd go for a scheme of N buffers in a ring per window. so you have
> buffers A,
> > B, C and you first render to A then display it, then next frame B, then
> C, then
> > A, then B, then C. You could get away without C. as the buffers retain
> their
> > state you can take advantage of this and only partially render part of a
> > buffer for updates "since 

Re: Best practices for client side buffer management

[Brad Robinson]

Hi Carsten,


> i assume GetTempPath() will be looking at /tmp ... and /tmp may not be a
> ramdisk. it may be a real disk... in which case your buffers may be getting
> written to an actual disk. don't use /tmp.
>

That's kind of what was in the back of my head when I decided to post this,
but being new to Linux dev thought it might have been a silly question and
wasn't sure how to express it.  Going to switch to memfd_create for now.


> resizes of windows are less common (in general) than rendering to them.
> here
> i'd go for a scheme of N buffers in a ring per window. so you have buffers
> A,
> B, C and you first render to A then display it, then next frame B, then C,
> then
> A, then B, then C. You could get away without C. as the buffers retain
> their
> state you can take advantage of this and only partially render part of a
> buffer for updates "since 1 or 2 frames ago" (depending if you do double or
> triple buffering). as its predictable ABCABCABC you can just keep a
> "Sliding
> window of the update regions of the past N frames" and merge those into the
> "current amount to update" but always store per-frame update rectangle
> regions
> before this merge-at-render-time. 3 buffers allows you to be rendering a
> 3rd
> buffer while 1 buffer is queued to be displayed and one is still being
> displayed. if you find you need a 4th buffer, perhaps just overdraw the
> 3rd on
> you just did and "update it" ... or just block or don't update yet as you
> are
> getting too far ahead of the compositor.
>
> > Finally, the toolkit already maintains an off-screen buffer with the
> > window's current contents rendered into it.  I'll probably replace that
> > with a Wayland buffer, but wondering about partial updates.  eg: if the
> > client only needs to redraw a part of the window what's the correct
> process
> > to update just that part with Wayland.  Can I just update the existing
> > buffer and prompt Wayland to just redraw that part?
>
> no. never do that. always have more than 1 and update a buffer that is not
> being displayed or queued to be displayed. the above sliding window allows
> your
> partial rendering to work as you can depend on previous content still being
> there where you left it from N frames ago.
>
>
OK thanks - that's pointing me in the right direction.  I have questions
about all this, but I don't want to waste your time until I've had time to
dig into it myself first.

(I'm a bit slow with all this because it's an evening side project and I'm
doing it in C# and trying to get the protocol bindings and libc pinvoke
functions all wired up at the same time as figuring out how it all works).

Brad
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Best practices for client side buffer management

[Brad Robinson]

Hi Scott,

Thanks - memfd_create looks like a good option.  I think I'll switch to
that and fall back if it's not available.

Sounds like one pool per window is the way to go...  really didn't feel
like implementing a heap allocator.

Brad


On Fri, Jun 19, 2020 at 1:55 PM Scott Anderson 
wrote:

> On 19/06/20 3:24 pm, Brad Robinson wrote:
> > Hi All,
> >
> > I'm fairly new to Wayland and Linux GUI programming in general, but
> > doing some experiments to figure out how to integrate it into my custom
> > UI toolkit library and have a couple of questions about client side
> > buffer management.
> >
> > Firstly, this is how I'm allocating the backing memory for client side
> > buffer pools.  This is C# p-invoking to libc, and basically it's using
> > mkstemp() to get a temp file, ftruncate() to set its length, mmap() to
> > map it and then unlink() once mapped so temp files aren't left behind.
> > Any issues with this approach?
> >
> >  // Get temp file
> >  var sb = new
> > StringBuilder(System.IO.Path.Join(System.IO.Path.GetTempPath(),
> > "mmXX"));
> >  int fd = mkstemp(sb);
> >  ftruncate(fd, (ulong)capacity);
> >
> >  // Map it
> >  var addr = mmap(IntPtr.Zero, (ulong)capacity, Prot.Read |
> > Prot.Write, Map.Shared, fd, 0);
> >
> >  // Unlink it (so temp files not left behind)
> >  unlink(sb.ToString());
>
> An alternative implementation would be to use memfd_create, but that is
> Linux-specific. Otherwise what you have there looks correct to me.
>
> > Secondly I'm wondering about practical strategies for managing client
> > side buffers.  The toolkit in question basically needs arbitrarily sized
> > buffers to render whatever size the window happens to be.  Seems like to
> > use a buffer pool for this would require some sort of heap manager to
> > manage what's in each pool.  I'm wondering if there's any
> > recommendations or best practices for how to deal with this.  eg: create
> > one big pool and explicitly manage what's in there as a heap, use lots
> > of little pools with one buffer in each, a combination of both,
> > something else?
>
> It would be possible to deal use heaps, but in practice most clients
> will just use a dedicated shared memory object (wl_shm_pool) for each
> buffer, which works perfectly fine. Shared memory clients usually only
> need 2 buffers, but it's a good idea to write your program in a way so
> that it can use up to 4, allocating the extra as needed, and freeing
> them when you're done.
>
> > Finally, the toolkit already maintains an off-screen buffer with the
> > window's current contents rendered into it.  I'll probably replace that
> > with a Wayland buffer, but wondering about partial updates.  eg: if the
> > client only needs to redraw a part of the window what's the correct
> > process to update just that part with Wayland.  Can I just update the
> > existing buffer and prompt Wayland to just redraw that part?
>
> There are requests in the protocol specifically for telling the
> compositor about partial updates, which are wl_surface.damage and
> wl_surface.damage_buffer. Using wl_surface.damage_buffer is generally a
> better idea.
>
> Here is a blog post that goes over some more general details:
> https://emersion.fr/blog/2019/intro-to-damage-tracking/
> It's slightly more slanted to talking about the compositor side of
> things, but I still think could be helpful.
>
> Scott
>
> > Any advice appreciated...
> >
> > Brad
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Best practices for client side buffer management

[Brad Robinson]

Hi All,

I'm fairly new to Wayland and Linux GUI programming in general, but doing
some experiments to figure out how to integrate it into my custom UI
toolkit library and have a couple of questions about client side buffer
management.

Firstly, this is how I'm allocating the backing memory for client side
buffer pools.  This is C# p-invoking to libc, and basically it's using
mkstemp() to get a temp file, ftruncate() to set its length, mmap() to map
it and then unlink() once mapped so temp files aren't left behind.  Any
issues with this approach?

// Get temp file
var sb = new
StringBuilder(System.IO.Path.Join(System.IO.Path.GetTempPath(),
"mmXX"));
int fd = mkstemp(sb);
ftruncate(fd, (ulong)capacity);

// Map it
var addr = mmap(IntPtr.Zero, (ulong)capacity, Prot.Read |
Prot.Write, Map.Shared, fd, 0);

// Unlink it (so temp files not left behind)
unlink(sb.ToString());

Secondly I'm wondering about practical strategies for managing client side
buffers.  The toolkit in question basically needs arbitrarily sized buffers
to render whatever size the window happens to be.  Seems like to use a
buffer pool for this would require some sort of heap manager to manage
what's in each pool.  I'm wondering if there's any recommendations or best
practices for how to deal with this.  eg: create one big pool and
explicitly manage what's in there as a heap, use lots of little pools with
one buffer in each, a combination of both, something else?

Finally, the toolkit already maintains an off-screen buffer with the
window's current contents rendered into it.  I'll probably replace that
with a Wayland buffer, but wondering about partial updates.  eg: if the
client only needs to redraw a part of the window what's the correct process
to update just that part with Wayland.  Can I just update the existing
buffer and prompt Wayland to just redraw that part?

Any advice appreciated...

Brad
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Language bindings for wl_registry_bind request

[Brad Robinson]

Hi Pekka,

the rule is that a 'new_id' type of argument *without* an 'interface'
> attribute extends to three arguments instead of one. The interface must
> be known at runtime, and if the XML does not give it, then it must be
> transmitted explicitly.
>

Great - glad to see this explicitly spelled out.

Brad
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Language bindings for wl_registry_bind request

[Brad Robinson]

Hi All,

I'm putting together a set of C# bindings for Wayland and it's coming along
nicely but I've hit an issue with wl_registry_bind where its implementation
doesn't seem to match the xml.

The wayland.xml file declares it as: (essentially one input parameter -
name)

 Binds a new, client-created object to the server using
the specified name as the identifier.




But the C implementation has additional version and interface parameters
and uses the wl_proxy_marshal_constructor_versioned - with apparently no
hints in the xml as to why.

static inline void *
wl_registry_bind(struct wl_registry *wl_registry, uint32_t name, const
struct wl_interface *interface, uint32_t version)
{
 struct wl_proxy *id;

 id = wl_proxy_marshal_constructor_versioned((struct wl_proxy *)
wl_registry,
 WL_REGISTRY_BIND, interface, version, name, interface->name,
version, NULL);

 return (void *) id;
}

Similarly the xml file would suggest the message signature should be "un",
but the C bindings have it as "usun".

What's going on here?  Is this a special case for this one method?

Brad
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Best practices for saving and restoring window layout

[Brad Robinson]

Hi All,

First post here...

I'm looking into porting an existing UI library to Gtk+ and I'm struggling
to solve a couple of problems related to window positioning when using
Wayland as the backend.

I've read through the posts on this list's archive about window positioning
and it's clear that a global coordinate system isn't something that Wayland
supports - fair enough and I understand the reasons why.

However, I'm wondering what the recommendations are for applications with
complicated user-controllable layouts that need to be persisted not only
across application runs, but also between documents and across application
modes.

For example:

* my application is a music app where the user might have many plugin
windows carefully positioned across multiple monitors.
* each document file has a different set of plugins loaded and those plugin
windows need to be restored to their previous location.
* the app can be in "Live" mode or "Edit" mode and switching between modes
saves and restores the plugin window locations for each mode.

How should such an app be handled under Wayland?

Note: the app doesn't need to be able to explicitly position windows. It
just needs a way to capture and restore a window's position.  An opaque
string or data structure that the app can save and use to later reposition
a window back to that same place would be perfect.  It would need to be
client persistable though - eg: giving a window an id that the window
manager can use to store previous geometry probably wouldn't suffice.

I'm about to refactor a big part of the code that handles this and now is
the time I can make conceptual changes that could better cater for Wayland
as a back end. I've seen comments in the archive about how a global
coordinate system isn't necessary and that issues related to a lack of one
can be better solved by other means but I'm not sure what those other means
are and I'm struggling to see a way forward with this.

Any thoughts, suggestions, recommendations greatly appreciated.

Brad
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel