Bug 100598

Summary: [EFL][AC] Fix bugs preventing us from running layout tests with AC turned on
Product: WebKit Reporter: Yael <yael>
Component: WebKit EFLAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: d-r, gyuyoung.kim, laszlo.gombos, lucas.de.marchi, rakuco, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
kenneth: review+
Patch for landing.
none
Patch for landing.
none
One more time . none

Yael
Reported 2012-10-27 16:45:47 PDT
Right now, all the tests crash when AC is turned on. If there are many issues, this bug should become a meta bug.
Attachments
Patch (3.51 KB, patch)
2012-10-28 20:33 PDT, Yael
kenneth: review+
Patch for landing. (3.64 KB, patch)
2012-10-29 05:42 PDT, Yael
no flags
Patch for landing. (3.68 KB, patch)
2012-10-29 06:16 PDT, Yael
no flags
One more time . (3.68 KB, patch)
2012-10-29 06:29 PDT, Yael
no flags
Yael
Comment 1 2012-10-28 20:33:44 PDT
Created attachment 171148 [details] Patch Make sure to use opengl_x11 engine when AC is turned on and X11 is in use. We cannot create a gl context otherwise.
Kenneth Rohde Christiansen
Comment 2 2012-10-28 23:10:39 PDT
Comment on attachment 171148 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=171148&action=review > Tools/EWebLauncher/main.c:813 > app->ee = ecore_evas_new(userArgs->engine, 0, 0, userArgs->geometry.w, userArgs->geometry.h, NULL); shouldn't that be indented now? > Tools/WebKitTestRunner/efl/PlatformWebViewEfl.cpp:39 > static Ecore_Evas* initEcoreEvas() > { > +#ifdef WTF_USE_ACCELERATED_COMPOSITING && defined HAVE_ECORE_X > + const char* engine = "opengl_x11"; > + Ecore_Evas* ecoreEvas = ecore_evas_new(engine, 0, 0, 800, 600, 0); > +#else > Ecore_Evas* ecoreEvas = ecore_evas_new(0, 0, 0, 800, 600, 0); > +#endif > if (!ecoreEvas) I would prefer const char* engine = 0; #ifdef WTF_USE_ACCELERATED_COMPOSITING && defined HAVE_ECORE_X engine = "opengl_x11"; #endif Ecore_Evas* ecoreEvas = ecore_evas_new(engine, 0, 0, 800, 600, 0); > Tools/DumpRenderTree/efl/DumpRenderTree.cpp:427 > +#ifdef WTF_USE_ACCELERATED_COMPOSITING && defined HAVE_ECORE_X > + const char* engine = "opelgl_x11"; > + Ecore_Evas* ecoreEvas = ecore_evas_new(engine, 0, 0, 800, 600, 0); > +#else > Ecore_Evas* ecoreEvas = ecore_evas_new(0, 0, 0, 800, 600, 0); > +#endif so much copied code, can't we concentrate it?
Yael
Comment 3 2012-10-29 05:42:38 PDT
Created attachment 171211 [details] Patch for landing. Take comment 2 into account. I don't see how to share code between DumpRenderTree and WebKitTestRunner, so did not combine the code.
Chris Dumez
Comment 4 2012-10-29 05:49:14 PDT
Comment on attachment 171211 [details] Patch for landing. View in context: https://bugs.webkit.org/attachment.cgi?id=171211&action=review > Tools/EWebLauncher/main.c:810 > +#ifdef WTF_USE_ACCELERATED_COMPOSITING && defined HAVE_ECORE_X I feel this is more readable: #if defined(WTF_USE_ACCELERATED_COMPOSITING) && defined(HAVE_ECORE_X) It looks odd to mix #ifdef and defined. It also decreases readability to use "defined" without parenthesis.
Gyuyoung Kim
Comment 5 2012-10-29 05:58:43 PDT
Comment on attachment 171211 [details] Patch for landing. View in context: https://bugs.webkit.org/attachment.cgi?id=171211&action=review > Tools/DumpRenderTree/efl/DumpRenderTree.cpp:422 > +const char* engine = 0; Nit : wrong indentation.
Yael
Comment 6 2012-10-29 06:13:56 PDT
(In reply to comment #5) > (From update of attachment 171211 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=171211&action=review > > > Tools/DumpRenderTree/efl/DumpRenderTree.cpp:422 > > +const char* engine = 0; > > Nit : wrong indentation. Oops :) The stylebot should have caught it.
Yael
Comment 7 2012-10-29 06:16:07 PDT
Created attachment 171219 [details] Patch for landing. Address comment #4 and comment #5 .
Gyuyoung Kim
Comment 8 2012-10-29 06:20:43 PDT
Comment on attachment 171219 [details] Patch for landing. View in context: https://bugs.webkit.org/attachment.cgi?id=171219&action=review > Tools/WebKitTestRunner/efl/PlatformWebViewEfl.cpp:33 > +const char* engine = 0; ditto ?
Yael
Comment 9 2012-10-29 06:27:25 PDT
(In reply to comment #8) > (From update of attachment 171219 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=171219&action=review > > > Tools/WebKitTestRunner/efl/PlatformWebViewEfl.cpp:33 > > +const char* engine = 0; > > ditto ? Fixed but didn't save :(
Yael
Comment 10 2012-10-29 06:29:22 PDT
Created attachment 171227 [details] One more time .
Dominik Röttsches (drott)
Comment 11 2012-10-29 06:47:58 PDT
(In reply to comment #4) > (From update of attachment 171211 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=171211&action=review > > > Tools/EWebLauncher/main.c:810 > > +#ifdef WTF_USE_ACCELERATED_COMPOSITING && defined HAVE_ECORE_X > > I feel this is more readable: > #if defined(WTF_USE_ACCELERATED_COMPOSITING) && defined(HAVE_ECORE_X) While we're at it, and I don't mean to halt the cq+, but shouldn't the first part be #if USE(ACCELERATED_COMPOSITING)?
Gyuyoung Kim
Comment 12 2012-10-29 07:03:21 PDT
(In reply to comment #11) > (In reply to comment #4) > > (From update of attachment 171211 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=171211&action=review > > > > > Tools/EWebLauncher/main.c:810 > > > +#ifdef WTF_USE_ACCELERATED_COMPOSITING && defined HAVE_ECORE_X > > > > I feel this is more readable: > > #if defined(WTF_USE_ACCELERATED_COMPOSITING) && defined(HAVE_ECORE_X) > > While we're at it, and I don't mean to halt the cq+, but shouldn't the first part be > #if USE(ACCELERATED_COMPOSITING)? As far as I know, we have to use USE(XXX) macro in WebKit inside because this macro is defined in Platform.h file. So, it seems to me that Tools can't use this. However, if Tools can use this, I think it is better to use USE() macro. To my quick search, Tools can use it. Yael, could you check this ?
Yael
Comment 13 2012-10-29 07:07:12 PDT
(In reply to comment #11) > (In reply to comment #4) > > (From update of attachment 171211 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=171211&action=review > > > > > Tools/EWebLauncher/main.c:810 > > > +#ifdef WTF_USE_ACCELERATED_COMPOSITING && defined HAVE_ECORE_X > > > > I feel this is more readable: > > #if defined(WTF_USE_ACCELERATED_COMPOSITING) && defined(HAVE_ECORE_X) > > While we're at it, and I don't mean to halt the cq+, but shouldn't the first part be > #if USE(ACCELERATED_COMPOSITING)? AFAIK USE() macro is defined only internally to webkit. EWebLauncher is not part of webkit itself and so the USE() macro is not defined.
Dominik Röttsches (drott)
Comment 14 2012-10-29 07:22:05 PDT
(In reply to comment #13) > (In reply to comment #11) > > (In reply to comment #4) > > > (From update of attachment 171211 [details] [details] [details]) > > > View in context: https://bugs.webkit.org/attachment.cgi?id=171211&action=review > > > > > > > Tools/EWebLauncher/main.c:810 > > > > +#ifdef WTF_USE_ACCELERATED_COMPOSITING && defined HAVE_ECORE_X > > > > > > I feel this is more readable: > > > #if defined(WTF_USE_ACCELERATED_COMPOSITING) && defined(HAVE_ECORE_X) > > > > While we're at it, and I don't mean to halt the cq+, but shouldn't the first part be > > #if USE(ACCELERATED_COMPOSITING)? > > AFAIK USE() macro is defined only internally to webkit. > EWebLauncher is not part of webkit itself and so the USE() macro is not defined. Alright, thanks for checking. Sorry for the noise then.
Gyuyoung Kim
Comment 15 2012-10-29 07:25:36 PDT
Comment on attachment 171227 [details] One more time . To my quick search, USE() is being used in Tools as well. However, I prefer to use USE() in WebKit inside only. cq+ again.
WebKit Review Bot
Comment 16 2012-10-29 07:30:09 PDT
Comment on attachment 171227 [details] One more time . Clearing flags on attachment: 171227 Committed r132799: <http://trac.webkit.org/changeset/132799>
WebKit Review Bot
Comment 17 2012-10-29 07:30:14 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.