Re: [E-devel] Evas/Elm resolution management

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

On Tue, Oct 4, 2011 at 9:30 AM, Christopher Michael
<cpm...@co...> 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

>> 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<
>> bar...@pr...>  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<
>>> kak...@ka...>  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
>>>> enl...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>>>
>>>
>>> --
>>> Gustavo Sverzut Barbieri
>>> http://profusion.mobi embedded systems
>>> --------------------------------------
>>> MSN: bar...@gm...
>>> 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
>>> enl...@li...
>>> 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
>> enl...@li...
>> 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
> enl...@li...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>

-- 
Cedric BAIL