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.
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.
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
