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
