For now, some results of pixel test are wrong. (For example, LayoutTests/fast/events/autoscroll.html) In order to fix this, I suggest capturing Ecore_Evas instead of painting webview.
Created attachment 129368 [details] Patch
Comment on attachment 129368 [details] Patch clear flags until I check how to rebase test cases.
Comment on attachment 129368 [details] Patch I checked png results which is newly failed. Some test cases are because of scrollbar. Although mockScrollbar is enabled, WebKit/Efl create native scrollbar. I will create new bug to fix them. The other test case is fast/forms/textarea-placeholder-set-attribute.html and it can be reproduce on EWeblauncher. (not always. 50% reproduced) So, I believe that patch is valid for bug. Could you review this?
Comment on attachment 129368 [details] Patch I realize that DRT/Efl(tiled) can not render scrolled contents with this patch correctly. (ex - compositing/geometry/fixed-position.html) So I cleared flags until I found proper way. BTW
(In reply to comment #4) > (From update of attachment 129368 [details]) > I realize that DRT/Efl(tiled) can not render scrolled contents with this patch correctly. > (ex - compositing/geometry/fixed-position.html) I created Bug 84933 for compositing/geometry/fixed-position.html
Comment on attachment 129368 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=129368&action=review Looks good API-wise, just make sure it doesn't cause test regressions. > Tools/DumpRenderTree/efl/PixelDumpSupportEfl.cpp:53 > + RefPtr<cairo_surface_t> viewSurface = adoptRef(cairo_image_surface_create_for_data((unsigned char*)pixels, CAIRO_FORMAT_ARGB32, width, height, width * 4)); Please use a C++-style cast here.
Created attachment 139416 [details] Patch
(In reply to comment #6) > (From update of attachment 129368 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=129368&action=review > > Looks good API-wise, just make sure it doesn't cause test regressions. > Thanks. There are no regression in my local. (compositing/geometry/fixed-position.html is in Skipped now.) > > Tools/DumpRenderTree/efl/PixelDumpSupportEfl.cpp:53 > > + RefPtr<cairo_surface_t> viewSurface = adoptRef(cairo_image_surface_create_for_data((unsigned char*)pixels, CAIRO_FORMAT_ARGB32, width, height, width * 4)); > > Please use a C++-style cast here. Done.
Comment on attachment 139416 [details] Patch The comments in 81315 mentioned this bug. Does one depend on the other?
(In reply to comment #9) > (From update of attachment 139416 [details]) > The comments in 81315 mentioned this bug. Does one depend on the other? I believe so.
Comment on attachment 139416 [details] Patch I'm happy to rubber-stamp this, but I"m not very useful for a real review.
Comment on attachment 139416 [details] Patch Clearing flags on attachment: 139416 Committed r116461: <http://trac.webkit.org/changeset/116461>
All reviewed patches have been landed. Closing bug.
Reopening to get some feedback. This commit appears to have broken the painting of scrollbars with both backing stores when running run-webkit-tests with --pixel-tests. Try running RWT on fast/box-sizing, for example.
(In reply to comment #14) > Reopening to get some feedback. This commit appears to have broken the painting of scrollbars with both backing stores when running run-webkit-tests with --pixel-tests. Try running RWT on fast/box-sizing, for example. I checked and reproduces it. Now, I realized that backing stores can not render mock scrollbars because they call Frame::paintContents instead of ScrollView::paint. Sorry, I will find a way to fix it but it will take more time.
I will revert this for now then, we can't stay with the buggy code.
Reverted in <http://trac.webkit.org/changeset/117879>.
ewebkit1 was dropped.