RESOLVED FIXED 41378
Compilation issues on chromium/linux with USE(ACCELERATED_COMPOSITING) 
https://bugs.webkit.org/show_bug.cgi?id=41378
Summary Compilation issues on chromium/linux with USE(ACCELERATED_COMPOSITING)
Antoine Labour
Reported 2010-06-29 15:13:36 PDT
platform/graphics/chromium/LayerRendererChromium.cpp and platform/graphics/chromium/LayerChromium.cpp use a windows-only skia call PlatformContextSkia::setDrawingToImageBuffer.
Attachments
Proposed fix (1.60 KB, patch)
2010-06-29 15:18 PDT, Antoine Labour 		dglazkov: review-
DetailsFormatted DiffDiff
Proposed patch, with updated ChangeLog and added FIXMEs (2.36 KB, patch)
2010-06-29 16:05 PDT, Antoine Labour 		no flags
DetailsFormatted DiffDiff
Updated patch, with tabs fixed. (2.37 KB, patch)
2010-06-29 16:13 PDT, Antoine Labour 		no flags
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Antoine Labour
Comment 1 2010-06-29 15:18:48 PDT
Created attachment 60065 [details] Proposed fix
Dimitri Glazkov (Google)
Comment 2 2010-06-29 15:28:30 PDT
Comment on attachment 60065 [details] Proposed fix This patch needs a ChangeLog. Also, can we somehow not have the ifdef here? Why is this call windows-specific?
Antoine Labour
Comment 3 2010-06-29 15:35:53 PDT
I don't know why the call is windows-specific :) But it's declared/defined in a #if OS(WINDOWS) in PlatformContextSkia. Given that all that call does is set a member variable, it may be ok to simply remove the #if there, but I don't know if it's appropriate.
Dimitri Glazkov (Google)
Comment 4 2010-06-29 15:38:43 PDT
(In reply to comment #3) > I don't know why the call is windows-specific :) But it's declared/defined in a #if OS(WINDOWS) in PlatformContextSkia. > Given that all that call does is set a member variable, it may be ok to simply remove the #if there, but I don't know if it's appropriate. Ha! Me neither. Let's land this as-is (with a ChangeLog, of course) with a FIXME (that's TODO in WebKit-speak) to investigate the disparity.
Antoine Labour
Comment 5 2010-06-29 16:05:00 PDT
Created attachment 60067 [details] Proposed patch, with updated ChangeLog and added FIXMEs
WebKit Review Bot
Comment 6 2010-06-29 16:07:24 PDT
Attachment 60067 [details] did not pass style-queue: Failed to run "['WebKitTools/Scripts/check-webkit-style', '--no-squash']" exit_code: 1 ChangeLog:5: Line contains tab character. [whitespace/tab] [5] Total errors found: 1 in 3 files If any of these errors are false positives, please file a bug against check-webkit-style.
Dimitri Glazkov (Google)
Comment 7 2010-06-29 16:09:33 PDT
(In reply to comment #6) > Attachment 60067 [details] did not pass style-queue: > > Failed to run "['WebKitTools/Scripts/check-webkit-style', '--no-squash']" exit_code: 1 > ChangeLog:5: Line contains tab character. [whitespace/tab] [5] > Total errors found: 1 in 3 files > > > If any of these errors are false positives, please file a bug against check-webkit-style. Hail style-elf! Can you fix that? Also, you can set commit-queue flag to "?" if you want the commit-queue to land it for you.
Antoine Labour
Comment 8 2010-06-29 16:13:43 PDT
Created attachment 60069 [details] Updated patch, with tabs fixed.
Antoine Labour
Comment 9 2010-06-29 16:40:30 PDT
Fixed the tab issue.
Dimitri Glazkov (Google)
Comment 10 2010-06-29 18:33:19 PDT
Comment on attachment 60069 [details] Updated patch, with tabs fixed. Alrighty.
WebKit Commit Bot
Comment 11 2010-06-29 18:53:02 PDT
Comment on attachment 60069 [details] Updated patch, with tabs fixed. Clearing flags on attachment: 60069 Committed r62157: <http://trac.webkit.org/changeset/62157>
WebKit Commit Bot
Comment 12 2010-06-29 18:53:07 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.