[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-03-11 Thread Michael Terry
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-03-11 Thread Daniel van Vugt
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-26 Thread Michael Terry
** 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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-24 Thread Michael Terry
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-24 Thread Daniel van Vugt
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-23 Thread Daniel van Vugt
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-21 Thread Michael Terry
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-21 Thread Alan Griffiths
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-20 Thread Michael Terry
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-20 Thread Daniel van Vugt
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-20 Thread Michael Terry
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-20 Thread Daniel van Vugt
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-19 Thread Daniel van Vugt
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.

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-19 Thread Michael Terry
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]

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-19 Thread Michael Terry
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-19 Thread Daniel van Vugt
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-19 Thread Daniel van Vugt
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-18 Thread Michael Terry
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-18 Thread Daniel van Vugt
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-18 Thread Chris Halse Rogers
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-18 Thread Daniel van Vugt
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-16 Thread Daniel van Vugt
** 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:

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-16 Thread Daniel van Vugt
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

[Bug 1280842] Re: [enhancement] Need a method of hiding surfaces until they are ready to draw themselves

2014-02-16 Thread Daniel van Vugt
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.