Bug 41378 - Compilation issues on chromium/linux with USE(ACCELERATED_COMPOSITING)
Summary: Compilation issues on chromium/linux with USE(ACCELERATED_COMPOSITING)
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-29 15:13 PDT by Antoine Labour
Modified: 2010-06-29 18:53 PDT (History)
5 users (show)

See Also:


Attachments
Proposed fix (1.60 KB, patch)
2010-06-29 15:18 PDT, Antoine Labour
dglazkov: review-
Details | Formatted Diff | Diff
Proposed patch, with updated ChangeLog and added FIXMEs (2.36 KB, patch)
2010-06-29 16:05 PDT, Antoine Labour
no flags Details | Formatted Diff | Diff
Updated patch, with tabs fixed. (2.37 KB, patch)
2010-06-29 16:13 PDT, Antoine Labour
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Antoine Labour 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.
Comment 1 Antoine Labour 2010-06-29 15:18:48 PDT
Created attachment 60065 [details]
Proposed fix
Comment 2 Dimitri Glazkov (Google) 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?
Comment 3 Antoine Labour 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.
Comment 4 Dimitri Glazkov (Google) 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.
Comment 5 Antoine Labour 2010-06-29 16:05:00 PDT
Created attachment 60067 [details]
Proposed patch, with updated ChangeLog and added FIXMEs
Comment 6 WebKit Review Bot 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.
Comment 7 Dimitri Glazkov (Google) 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.
Comment 8 Antoine Labour 2010-06-29 16:13:43 PDT
Created attachment 60069 [details]
Updated patch, with tabs fixed.
Comment 9 Antoine Labour 2010-06-29 16:40:30 PDT
Fixed the tab issue.
Comment 10 Dimitri Glazkov (Google) 2010-06-29 18:33:19 PDT
Comment on attachment 60069 [details]
Updated patch, with tabs fixed.

Alrighty.
Comment 11 WebKit Commit Bot 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>
Comment 12 WebKit Commit Bot 2010-06-29 18:53:07 PDT
All reviewed patches have been landed.  Closing bug.