[EFL] Do not crash if the Cairo surface cannot be created.
Created attachment 102028 [details] Patch
CC'ing mrobinson instead of tkent, as this is cairo-related.
Comment on attachment 102028 [details] Patch Attachment 102028 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/9251384
Wouldn't it be better to use the current clip to figure out how big the surface should be rather than to just fail?
Created attachment 102164 [details] Patch
Comment on attachment 102164 [details] Patch The 'return false' substituting 'return true' in themePartCacheEntrySurfaceCreate() shouldn't be there.
Created attachment 102179 [details] Patch
Comment on attachment 102179 [details] Patch By my comment I actually was asking whether or not you could simply cache only what's within the clipping region, versus allocating a cache area the size of the entire widget.
Sorry for leaving this one behind for so long. I was talking to Leandro about your question/suggestion a few minutes ago. If we were to cache what's visible, wouldn't we need to keep track of viewport size changes and all that, making the code much bigger?
(In reply to comment #9) > Sorry for leaving this one behind for so long. > > I was talking to Leandro about your question/suggestion a few minutes ago. If we were to cache what's visible, wouldn't we need to keep track of viewport size changes and all that, making the code much bigger? I don't know exactly how your theme cache works, but it seems that if you should already be checking whether the widget changes size each time you draw. You'd just need to add one more condition determining whether or not the clip region has moved or changed size. I'm not sure how feasible that is.
(In reply to comment #10) > I don't know exactly how your theme cache works, but it seems that if you should already be checking whether the widget changes size each time you draw. You'd just need to add one more condition determining whether or not the clip region has moved or changed size. I'm not sure how feasible that is. After spending some time on this, it looks like implementing this suggestion could be feasible, but would require quite some effort. On the one hand, Edje (which actually renders the theme) has a hardcoded limit of 20000x20000 pixels for a widget's dimensions; on the other hand, the way RenderThemeEfl is currently implemented makes it a bit difficult to track the clipping region and decide where exactly in the cairo context to paint the rendered element (when scrolling, scaling and other things are taken into account it becomes even harder). For now, I think it's OK to just not display elements which are too big (a 1-month-old GtkLauncher build I have here just displays the top of the textarea in the mentioned testcase, and my distro's Chromium displays mostly garbage after some point too). I'm submitting a new patch with a better heuristic in a few minutes.
Created attachment 106118 [details] Patch
Created attachment 106419 [details] Be less strict about what sizes we consider to be invalid
Comment on attachment 106419 [details] Be less strict about what sizes we consider to be invalid Clearing flags on attachment: 106419 Committed r94578: <http://trac.webkit.org/changeset/94578>
All reviewed patches have been landed. Closing bug.