Latest mir/devel works great for this, thanks to Alan's nested fixes.
Will close.
** Changed in: mir (Ubuntu)
Status: Opinion = Fix Released
** Changed in: mir
Status: Opinion = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
The enhancement was not implemented. It was resolved by bug fixes.
Probably bug 1284739 whose fix is coming in Mir 0.1.7.
** Changed in: mir
Status: Fix Released = Won't Fix
** Changed in: mir (Ubuntu)
Status: Fix Released = Won't Fix
--
You received this bug notification because
** Changed in: mir
Assignee: (unassigned) = Alan Griffiths (alan-griffiths)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1280842
Title:
[enhancement] Need a method of hiding surfaces until
Daniel, I think the idea was that we have a method of knowing when a
surface is ready to be shown today (the compositor can hook into
surfaces to know when they have swap_buffer called on them). So USC can
just wait for that to happen with a non-null buffer to know that the
surface is ready.
So
Assuming the 4-buffer bug is fixed (which I think should be logged as a
separate bug), then you can use should_be_rendered_in() or whatever
comes along to replace it. Fortunately I am now in progress merging
CompositingCriteria with Renderable which will be a richer, more useful
and more logical
I'm a bit lost after the above comment. If there is a nesting-only bug I
think it would be useful to describe that more concisely in a new bug
report.
As for this enhancement request, it's still almost reasonable to just
implement (comment #2). But we shouldn't do so while there appears to be
Talked more on IRC about this. kdub is doing some reworking of how
CompositingCriteria is exposed which might help.
But more importantly, Alan thinks the four buffer swaps are just a bug
with nested compositing mode. If that were fixed, I think we'd be
good...
--
You received this bug
mterry alan_g, it's not even *my* scenario. It's just a client calling
mir::run_mir
mterry alan_g, something about constructing/running a DisplayServer causes 4
buffers to be swapped
alan_g mterry: so this client is a nested server?
mterry alan_g, yeah
mterry alan_g, (this is all in the context
Daniel, I don't think this is a duplicate of bug 1279422. This is about
the compositor being able to hide surfaces. That bug is about letting a
session execute its internal code.
About BasicSurface, OK. I get that it's an internal implementation
class. But do a grep for for
I did a grep, and the interface for getting to CompositingCriteria is public
already, apparently:
include/server/mir/compositor/scene.h
That said, the whole team would like to abolish CompositingCriteria and
merge it with a less abstract surface class. That way we can for example
give the
We talked about this a bit on IRC. The API in scene.h is not sufficient
to match Criteria to Surfaces. And thus isn't of much real use. This
is apparently a known deficiency. Just hasn't been address yet.
kdub is apparently working in this space. I'll talk to him to see .
--
You received
You can see the deficiency when GLRenderer needs a unique surface ID. The real
surface ID is not accessible right now:
http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/server/compositor/gl_renderer.cpp#L250
--
You received this bug notification because you are a
mterry,
Yep, there's a bug in Mir. Not Mir exactly, but Mesa where it supports
Mir. I assume you're only seeing problems on desktop/Mesa?... See bug
1281938.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I'm testing on mako. So not that bug. But maybe it's just normal
startup buffers... Will look at be_rendered_in next
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1280842
Title:
[enhancement]
So trying to use should_be_rendered_in() seems impossible for a 3rd
party (i.e. unity-system-compositor).
The CompositingCriteria class itself is exposed, but BasicSurface isn't,
which is what would actually make it useful. As is, there's no way to
get access to a Criteria instance for a
BasicSurface is an internal implementation class that shouldn't be
exposed, and isn't. So that's correct.
If you look at Mir's src/server/compositor/* you will see all the
compositor logic including several uses of should_be_rendered_in(), and
none of it uses BasicSurface at all. Just
Is this a duplicate of bug 1279422?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1280842
Title:
[enhancement] Need a method of hiding surfaces until they are ready to
draw themselves
To manage
Mir simply hides a surface until you've explicitly showed it by calling
swapbuffers.
Right. I get that that's how Mir is *supposed* to work. But I'm saying
that calling mir::run_mir() in the client calls swap_buffers() four
times on the server before even giving control back to the client.
So
you've explicitly showed it by calling swapbuffers.
means swap buffers on the _client_. That's completely unrelated to swap buffers
on the server (which happens on startup yes).
Mir's default compositor won't (shouldn't) show a surface until there's
a buffer completed by the client. And the
Yeah, that would be a bug :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1280842
Title:
[enhancement] Need a method of hiding surfaces until they are ready to
draw themselves
To manage
Hmm, seems there might be a Mir bug at play -- bug 1281938
But that doesn't change the fact that all compositors need to call
should_be_rendered_in() to cull the list of surfaces that gets rendered.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Summary changed:
- Need a method of hiding surfaces until they are ready to draw themselves
+ [enhancement] Need a method of hiding surfaces until they are ready to draw
themselves
** Changed in: mir (Ubuntu)
Status: Confirmed = Triaged
** Changed in: mir (Ubuntu)
Importance:
On one hand I think this makes a lot of sense. All existing toolkits
have show/hide functionality. On the other hand, Mir's current approach
makes sense and negates the need for show/hide. Mir simply hides a
surface until you've explicitly showed it by calling swapbuffers.
The compositor calls
Incidentally, should_be_rendered_in() also checks an internal hidden
flag. That flag is already implemented on the server but there's no
client API for it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
24 matches
Mail list logo