On 10/04/2011 03:36 AM, Cedric BAIL wrote:
> On Tue, Oct 4, 2011 at 9:30 AM, Christopher Michael
> <cpmicha...@comcast.net> wrote:
>> On 10/03/2011 10:06 PM, Youness Alaoui wrote:
>>> Hey Gustavo!
>>> Thanks for answering my email! It's appreciated.
>>> However it didn't answer my questions, because basically, no, I'm not going
>>> to implement a window manager for the PS3 :) Don't forget that all
>>> applications/games will be full screen windows, and that 0.1% of people (a
>>> lot less I'm sure) actually have a mouse/keyboard hooked to their ps3, so
>>> having multiple windows is not a solution. I'm ok with single window apps,
>>> and while I do want to have interoperability with existing EFL apps without
>>> (or few) modifications, I mostly want something for new app development and
>>> a clear API on how to change resolution and how to handle the situation I
>>> explained.. most importantly, I'm not going to implement a WM, compositor,
>>> wayland or anything fancy like that :)
>>> I am not focusing on multi window apps, in my previous email, when I said I
>>> used elementary_test, I failed to mention I only ran it with --test-win-only
>>> to make sure only one window is created, so this is not the issue here.
>>>
>>> I like the screen_geometry_set and screen_modes_list, but I think they
>>> should go into evas or ecore-evas rather than elm, because they might be
>>> useful to people not using elm.
>>
>> Agree with this...tho perhaps ecore_x is a better place ?? Then it would
>> be available to ecore_evas or other apps outside via Ecore_X ?
>>
>>> E17 has a resolution config dialog, how does it get/set the screen's
>>> resolution? I suppose by using xrandr or something like that? maybe we can
>>> abstract that into evas directly, this way it would work on non-X backends
>>> like framebuffer/ps3.
>>>
>> ecore_x_randr_screen_primary_output_current_size_get
>> ecore_x_randr_screen_primary_output_orientation_get
>> ecore_x_randr_screen_primary_output_refresh_rates_get
>>
>> So on and so forth....
>>
>> Hence why I think (with the above) that ecore_x would be a better place...
>
> Hum, he doesn't have X on it's PS3, so maybe Ecore_Evas would be the
> right place to add this stuff and could use ecore_x when under X.
>
> Cedric
>
Ahhh, well without X then being in ecore_x would be pointless :/ Yea,
ecore_evas then ;)
dh
>>> What I have done for now is use the fullscreen flag to decide whether or not
>>> to call the resized callback with the full screen size (scale or resize
>>> window). If we add the modes_list and screen_geometry_set functions then it
>>> would fix a few of the issues I had.
>>>
>>> Thank you,
>>> Youness.
>>>
>>>
>>> On Sat, Oct 1, 2011 at 10:51 AM, Gustavo Sverzut Barbieri<
>>> barbi...@profusion.mobi> wrote:
>>>
>>>> Hi kakaroto, I'm at an event and I assume I couldn't read it all, but ad
>>>> I'm
>>>> postponing the reply and nobody else did, here comes my main concern and
>>>> idea:
>>>>
>>>
>>>> The mapping is not the best one. Instead of window to screen, it would
>>>> be
>>>> better to have something else that maps to screen and inside it a window.
>>>>
>>>> Think wayland, but we all will complain about porting it.
>>>>
>>>> That said, to simplify stuff I propose: create a simple hardware screen
>>>> manager. It would list and set resolution, defaults to highest. Windows are
>>>> painted inside it, even composited and fullscreen case handled. Windows
>>>> decorations and positioning can be handled or not.
>>>>
>>>> Main concerns: damn will we create another x11? Why not port it? Why not
>>>> wayland? IMHO it is not worth the effort, because we're focusing single
>>>> process apps with multi windows.
>>>>
>>>> Implementation proposal: create 2 ecore-evas, one setups the actual
>>>> hardware
>>>> (done) and another that talks to it and maps ecore-evas to inner windows in
>>>> main ecore-evas. Composition is for free, etc. Would be useful for
>>>> framebuffer and sdl as well. Elm could just use this second one only.
>>>> Optimizations can come later on how to use hardware acceleration and maybe
>>>> avoid double buffeting for fullscreen windows.
>>>>
>>>> Window decorations and handling: well need it in elm if we go to wayland
>>>> and
>>>> want to run in desktops.
>>>>
>>>> Todo:
>>>> - ecore_evas_engine_modes_list("engine") -> [{width, height, depth,
>>>> "options string"}, ...]
>>>> - elm: engine using ecore_evas_object_image_add(). It would create and
>>>> manage Ecore_Evas used to hold it, sets to highest or given in $ELM_ENGINE
>>>> or config
>>>>
>>>> Extra:
>>>> - elm_screen_geometry_{get,set}() -> bool (may fail)
>>>> - elm_screen_modes_list()
>>>> - window decorations and management provided automatically by elm if in
>>>> sub window mode
>>>>
>>>> Comments?
>>>>
>>>>
>>>>
>>>> On Wednesday, September 28, 2011, Youness Alaoui<
>>>> kakar...@kakaroto.homelinux.net> wrote:
>>>>> Hi all,
>>>>>
>>>>> As you know, I'm doing the PS3 port of the EFL and I'm finding myself in
>>>> a
>>>>> bit of a tricky situation, let me explain :
>>>>> The PS3 is a console that outputs to a TV... TVs can do different
>>>>> resolutions, 480, 720p or 1080p (as well as a few others). The SDK allows
>>>> us
>>>>> to know what the TV screen supports, and we can choose to switch to
>>>> whatever
>>>>> resolution we want that the TV supports.
>>>>> What I initially did in the evas engine was that I would take whatever
>>>> size
>>>>> the application requested (evas_output_size_set) and set my buffer to it,
>>>>> then find the closest matching resolution (the smallest difference in
>>>> area
>>>>> between that resolution and the resolutions supported by the TV), and set
>>>>> the TV to that res, then scale the output when I draw on screen. So
>>>>> basically, you'd resize your evas to 200x200 and it would be seen
>>>> internally
>>>>> as 200x200 but the engine would scale it to 720x480 for the screen.
>>>>>
>>>>> The issue came when I ported elementary. Most (all?) elementary tests
>>>> (from
>>>>> elementary_test app) would create the evas with resolution 1x1 then they
>>>>> would resize the window to whatever they want, but I never received that
>>>>> size change request and my buffer would stay at 1x1 and scale that up.
>>>> The
>>>>> reason is that the ecore_evas_resize has a nice little check :
>>>>> if (ee->prop.fullscreen) return;
>>>>> so the resize would never work. I 'fixed' it by removing the fullscreen
>>>> flag
>>>>> for the ps3 engine.
>>>>>
>>>>> Other issue I got was that when I scale, I lose the aspect ratio which
>>>> might
>>>>> look great. so I'm thinking of adding a way to tell the engine if we want
>>>> to
>>>>> keep the aspect ratio (then it would center the scaled image on screen)
>>>> or
>>>>> stretch it completely. Is there a way to set this up natively with the
>>>> API
>>>>> without having an engine specific option ?
>>>>> Raster said that fullscreen engines need to tell the screen resolution to
>>>>> the app, so what I did was to also add a call to the resize callback
>>>> after
>>>>> we get resized, more precisely, you set your window to 200x200, you get a
>>>>> resize callback of your 200x200 then it will fetch the real current
>>>>> resolution (720x480) then send another resize callback with the full
>>>>> resolution. Question here, should I do it like that or should I only sent
>>>> a
>>>>> single resize callback? Most importantly, what happens when the client
>>>>> didn't register his callback yet? for example, eskiss would do the
>>>>> ecore_evas_new with its 1280x768 resolution request, *then* do the
>>>>> callback_resize_set (but it's too late since the resize callback was
>>>>> 'called' during the new), and since it never calls the ecore_evas_resize
>>>>> afterwards, it never knows that the evas it's working on has been
>>>> resized.
>>>>> What should be the fix for that? should the
>>>> ecore_evas_callback_resize_set
>>>>> call the callback with the current resolution the first time it's called?
>>>> Or
>>>>> should we workaround it by always creating 1x1 windows and then call the
>>>>> ecore_evas_resize after we set a callback (in which case it might cause
>>>> the
>>>>> tv screen to switch resolutions twice for no reason)?
>>>>>
>>>>> Finally, my current biggest design issue, is how to decide whether or not
>>>> to
>>>>> tell the application that it has been resized to fit the screen. In other
>>>>> words, what if someone wants the window to be 200x200 and get scaled and
>>>>> doesn't actually want to be rendering on 720x480? What if the window has
>>>> a
>>>>> min/max size set to it? In the case of eskiss, I get a smooth 60fps on
>>>>> 1280x768, but when it tries to draw on any other resolution, its
>>>> performance
>>>>> drops to 2 or 3 fps (I still have no idea what causes this performance
>>>>> loss), so for eskiss for example, I wouldn't want to have the resize
>>>>> callback called and evas_output_size_set called to resize evas to the
>>>> screen
>>>>> resolution, I'd want it to stay at 1280x768 and have the engine scale
>>>> that
>>>>> to whatever the screen wants (and even if we fixed that performance
>>>> issue,
>>>>> if the TV only supports 480p SD resolutions, eskiss just won't work
>>>> because
>>>>> the levels and menus, etc.. were not designed for anything less than
>>>>> 1280x768.. and they will not look good on 1920x1080 either).
>>>>> One thought I had was the fullscreen flag.. if the fullscreen flag is
>>>> set,
>>>>> then I'd call the resize callback and resize evas to fit the screen
>>>>> resolution, if it's not set, then I would just scale. This brings up the
>>>>> issue of the ecore_evas_resize not working in fullscreen mode.. what if I
>>>>> want to change the screen resolution? I'd have to unset the fullscreen
>>>> flag,
>>>>> then resize, then set it back again (imagine a game where you can choose
>>>> the
>>>>> fullscreen resolution in the game's video options). That seems like an
>>>> ugly
>>>>> hack.
>>>>> Maybe I should use the maximized flag instead in that case.. in which
>>>> case,
>>>>> does any of these flags affect how evas/ecore_evas/elementary work? or is
>>>>> that only engine specific stuff ? Obviously the fullscreen flag affects
>>>>> ecore_evas (since it skips the resize command), will there be any other
>>>>> similar side effects if I make the window have the maximized flag or not?
>>>> I
>>>>> feel like it would make sense to have the engine set the maximized and
>>>>> fullscreen flags, because that's how it really is, and it seems the EFL
>>>> was
>>>>> not designed for these use cases..
>>>>>
>>>>> What do you think? Any suggestions as to how to design this so it fits
>>>> the
>>>>> EFL design and it works properly and allows for all our use cases without
>>>>> any hackish workarounds?
>>>>>
>>>>> I know this was a long email, sorry about that... To summarize, here were
>>>>> the questions I asked for which I'd like an answer :
>>>>> - Is there a way to tell the engine to stretch/scale/keep aspect ratio,
>>>>> using the current API, or should I set an engine specific option ?
>>>>> - Should I send two resize callback (one for the requested size followed
>>>> the
>>>>> screen size) or a single one (final resolution) when a resize is
>>>> requested?
>>>>> - How can we fix the issue where the window gets resized between the call
>>>> to
>>>>> _new and _callback_resize_set? Have the callback_resize_set call the
>>>>> callback right away with the current resolution ?
>>>>> - How should I decide on whether to scale or not the window (call the
>>>> resize
>>>>> callback with the current screen or leave it as is and just scale the
>>>>> window) ?
>>>>> - How can I handle the min/max properties on a window ?
>>>>> - What side effects does the maximize and fullscreen flag have other than
>>>>> engine specific, for non-windowed systems ?
>>>>>
>>>>> Thank you!
>>>>> KaKaRoTo
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>> All the data continuously generated in your IT infrastructure contains a
>>>>> definitive record of customers, application performance, security
>>>>> threats, fraudulent activity and more. Splunk takes this data and makes
>>>>> sense of it. Business sense. IT sense. Common sense.
>>>>> http://p.sf.net/sfu/splunk-d2dcopy1
>>>>> _______________________________________________
>>>>> enlightenment-devel mailing list
>>>>> enlightenment-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>>>>
>>>>
>>>> --
>>>> Gustavo Sverzut Barbieri
>>>> http://profusion.mobi embedded systems
>>>> --------------------------------------
>>>> MSN: barbi...@gmail.com
>>>> Skype: gsbarbieri
>>>> Mobile: +55 (19) 9225-2202
>>>>
>>>> ------------------------------------------------------------------------------
>>>> All of the data generated in your IT infrastructure is seriously valuable.
>>>> Why? It contains a definitive record of application performance, security
>>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>>> sense of it. IT sense. And common sense.
>>>> http://p.sf.net/sfu/splunk-d2dcopy2
>>>> _______________________________________________
>>>> enlightenment-devel mailing list
>>>> enlightenment-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>>>
>>> ------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure contains a
>>> definitive record of customers, application performance, security
>>> threats, fraudulent activity and more. Splunk takes this data and makes
>>> sense of it. Business sense. IT sense. Common sense.
>>> http://p.sf.net/sfu/splunk-d2dcopy1
>>> _______________________________________________
>>> enlightenment-devel mailing list
>>> enlightenment-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>>
>
>
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
