| === Stskeepz is now known as Stskeeps | ||
| 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:40 |
| slvn_ | It would be nice if someone could consider it ! | 07:41 |
| slvn_ | This is my last blocker to submit application for ubuntu touch | 07:41 |
| === tvoss|food is now known as tvoss | ||
| tvoss | slvn_, thanks for the bug report :) | 08:04 |
| 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:55 |
| 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:56 |
| 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:58 |
| 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 | 08:59 |
| 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 ! | 09:00 |
| === renato is now known as Guest37257 | ||
| 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:28 |
| 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:52 |
| alan_g | That would be good to establish | 12:54 |
| 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 | 12:57 |
| === dandrader is now known as dandrader|afk | ||
| 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:11 |
| 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:12 |
| alf__ | kdub_: right, that was the point, create a DisplayBufferCompositor tailor-made for each displaybuffer | 13:13 |
| kdub_ | I'm still missing some part of the argument | 13:15 |
| kdub_ | alf__, ^^ | 13:18 |
| 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:19 |
| kdub_ | the gl program adjusts | 13:20 |
| kdub_ | I guess the real win in terms of ease of use is moving the SceneElementSequence | 13:20 |
| 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:22 |
| alf__ | kdub_: One dbc per displaybuffer? I am confused, I thought that you were suggesting a single dbc for all? | 13:24 |
| kdub_ | no, just shifting how the DisplayBufferCompositor gets the DisplayBuffer | 13:25 |
| 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:26 |
| alf__ | kdub_: ok, without a factory how do we create new DisplayBuffers in MultiThreadedCompositor when the configuration changes? | 13:28 |
| === dandrader|afk is now known as dandrader | ||
| 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:29 |
| 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:35 |
| kdub_ | socratic method... the true greek way :D | 13:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!