[TTVD] Use dummy geometry when preparing video decoder

Some boards struggles when unmuting with zero-geometry
(e.g PontusM). When it happens, process of decoder
initialization is stuck, giving no video frame to client.
This CL changes behavior of scaler preparation when
initializing video decoder, so smallest possible
geometry (1x1) is used.

Bug: https://jira-eu.sec.samsung.net/browse/VDGAME-529
Change-Id: I2d86cd28730ffb05660335dd773042ae9ffca4d9
Signed-off-by: Jakub Gajownik <j.gajownik2@samsung.com>

diff --git a/tizen_src/chromium_impl/ui/ozone/platform/efl/output_surface_manager.cc b/tizen_src/chromium_impl/ui/ozone/platform/efl/output_surface_manager.cc
index 996188156d1597b5cfef880cc7249c1aa8b68c13..39bca8ef6918e055e28a8691965ba6818b85edd9 100644 (file)
--- a/tizen_src/chromium_impl/ui/ozone/platform/efl/output_surface_manager.cc
+++ b/tizen_src/chromium_impl/ui/ozone/platform/efl/output_surface_manager.cc
@@ -215,9 +215,13 @@ OutputSurfaceManager::PrepareNewSurface(
       break;
   }
 
-  // At this point we have no information about the quad to be rendered, that's
-  // why |overlay_plane_data| is default-initialized.
+  // At this point we have no information about the quad to be rendered, so we
+  // cannot fill it with proper informations. Some platforms might struggle with
+  // rendering video into zero-size rectangle (and thus properly initializing
+  // scaler and unmute it), so start with 1x1 area.
   gfx::OverlayPlaneData overlay_plane_data;
+  overlay_plane_data.display_bounds = gfx::RectF(1.0f, 1.0f);
+  overlay_plane_data.damage_rect = gfx::Rect(1920, 1080);
 
   // Since preparing surface is done aside of normal rendering process, it's
   // possible that surface is acquired by different collection. So we cannot