=== Stskeepz is now known as Stskeeps
[07:40] <slvn_> Hi, I have posted a feature request on libmirclient
[07:40] <slvn_> https://bugs.launchpad.net/mir/+bug/1382209
[07:40] <ubot5> Ubuntu bug 1382209 in Mir "[Enhancement] Add an API to lock surface orientation" [Undecided,New]
[07:41] <slvn_> It would be nice if someone could consider it !
[07:41] <slvn_> This is my last blocker to submit application for ubuntu touch
=== tvoss|food is now known as tvoss
[08:04] <tvoss> slvn_, thanks for the bug report :)
[08:55] <slvn_> tvoss, you're welcome ! I need this feature, to publish my SDL application ! I need anyone porting an SDL game, or any native application will need this feature !
[08:55] <slvn_> I  think anyone porting an SDL game, or any native application will need this feature !
[08:56] <tvoss> slvn_, yup, I think I know what you are after. Out of curiosity: did you use our sdl 2 backend for porting purposes?
[08:58] <slvn_> tvoss,  yes of course !   I have had any talks and help with bschaefer about it ! and I also a reported a few minors fixes
[08:58] <tvoss> slvn_, awesome, thank you
[08:59] <slvn_> (and I got help from many people here ! for cross-compiling and making think works)
[08:59] <tvoss> slvn_, great,thanks for the feedback :)
[08:59] <slvn_> s/think/thing
[09:00] <slvn_> from my point of view. Developing native app on ios/android/winrt/nacl/macox/linux
[09:00] <slvn_> the main blocker remaining to develop native app
[09:00] <slvn_> is this orientation issue !
=== renato is now known as Guest37257
[12:28] <kdub_> alan_g, are you working on https://code.launchpad.net/~alan-griffiths/mir/spike-making-render_surfaces-an-example/+merge/238562/comments/586081 ? If not I'll take it up
[12:52] <alan_g> kdub_: I'm not - what are you thinking of doing with it?
[12:52] <kdub_> alan_g, just seeing if its possible to just override the DisplayBufferCompositor, and get rid of the factory
[12:54] <alan_g> That would be good to establish
[12:57] <kdub_> its looking easier to use so far
[12:57] <kdub_> we don't have to make the overriding code fiddle with our funny compositor id system
=== dandrader is now known as dandrader|afk
[13:11] <alf__> kdub_: Note that the factory is there so that the implementation could: 1. Provide customized/optimized DisplayBufferCompositors for maximum performance (e.g. with a gl renderer tailor-made for each display buffer)
[13:11] <alf__> kdub_: 2. Easily handle dynamic construction/destruction of DisplayBufferCompositors as display configurations change
[13:11] <kdub_> alf__, but as it is, one DisplayBufferCompositor is made for each displaybuffer
[13:12] <kdub_> and, as things change, it seems easier to just adjust the existing gl program than construct a new one
[13:12] <kdub_> but its good to keep in mind
[13:13] <alf__> kdub_: right, that was the point, create a DisplayBufferCompositor tailor-made for each displaybuffer
[13:15] <kdub_> I'm still missing some part of the argument
[13:18] <kdub_> alf__, ^^
[13:19] <alf__> kdub_: ok, so, what is the plan for handling multiple display buffers internally in the new version of DBC? (e.g. two different calls from different threads for dbc.composite(db1,...) dbc.composite(db2,...) ?
[13:20] <kdub_> the gl program adjusts
[13:20] <kdub_> I guess the real win in terms of ease of use is moving the SceneElementSequence
[13:22] <alf__> kdub_: note that dbc.composite() calls could be concurrent, we can't have a single gl program, we need one for each displaybuffer
[13:22] <kdub_> well right, one dbc per displaybuffer
[13:24] <alf__> kdub_: One dbc per displaybuffer? I am confused, I thought that you were suggesting a single dbc for all?
[13:25] <kdub_> no, just shifting how the DisplayBufferCompositor gets the DisplayBuffer
[13:26] <kdub_> right now, we force the implementers of DisplayBuffer to go through the DisplayBufferCompositorFactory and their own constructors to get the DisplayBuffer to use
[13:28] <alf__> kdub_: ok, without a factory how do we create new DisplayBuffers in MultiThreadedCompositor when the configuration changes?
=== dandrader|afk is now known as dandrader
[13:29] <kdub_> I'm a bit more focused on making the DisplayBufferCompositor::composite easier to use
[13:29] <kdub_> still not sure if getting rid of the factory is doable
[13:29] <kdub_> still exploring
[13:35] <alf__> kdub_: sure, I am trying to use the socratic method (on both of us :)) to bring to the surface all the parameters that may affect the decision.
[13:37] <kdub_> socratic method... the true greek way :D