[webkit-efl] Fixing --no-tiled-backing-store build
Ed Bartosh
bartosh at gmail.com
Fri Mar 29 08:46:44 PDT 2013
Hi Kalyan,
2013/3/29 kalyan kondapally <kondapallykalyan at gmail.com>
> Hi Ed,
>
>
> >other option for every commit, but this is very resource-consuming.
> Alternatively it might make sense to get rid of as >many options as we can
> if we can't ensure that non-default builds don't fail. This will at least
> make code much more >readable as a lot of #ifs will be cleaned up.
>
> Also it adds an overhead for each developer contributing code to ensure we
> don't have regression in both cases.
>
> From other point of view what's the reason of having build options that
don't work? Much fair would be not to have them at all.
I was actually talking not just about this build option. Ideally every
option and every options combination should be checked. However, in real
world it's just impossible as every additional build will double amount of
needed build resources.
> You should ask in #webkit channel, to add edit bug permissions for your
> account.
>
> Thanks. I will.
>
> On Fri, Mar 29, 2013 at 5:20 PM, Ed Bartosh <bartosh at gmail.com> wrote:
>
>> Hi *Kalyan,*
>> *
>> *
>> *Thank you for your suggestions. I'll split the bug. It looks like "one
>> patch for one bug" rule is assumed in the current workflow as tools like
>> webkit-patch automatically obsolete previous patches in the bug when new
>> one is uploaded.*
>> *
>> *
>> *BTW, another newbie question: How can I assign myself to the bug? Or
>> should I ask someone else with sufficient rights to do that?
>> *
>>
>> Regarding support --no-tiled-backing-store I also thought that one of the
>> possible ways to go is to drop support of it completely. However, in
>> current situation it means that developers using latest versions of major
>> Linux distros are blocked by this issue.
>>
>> Another point is how to avoid this kind of breakages in the future. As
>> Laszlo mentioned in the bug without being continuously tested builds with
>> non-default options will tend to regress to build failures. From my point
>> of view it boils down to the amount of build resources we have for testing.
>> It's not a big deal to run build with --no-tiled-backing-store or other
>> option for every commit, but this is very resource-consuming. Alternatively
>> it might make sense to get rid of as many options as we can if we can't
>> ensure that non-default builds don't fail. This will at least make code
>> much more readable as a lot of #ifs will be cleaned up.
>>
>> Regards,
>> Ed
>>
>>
>> 2013/3/29 kalyan kondapally <kondapallykalyan at gmail.com>
>>
>>> HI Ed,
>>>
>>> Thanks for the effort.
>>>
>>> Reg Adding checks:
>>>
>>> With X fix in, it boils down to whether we want to support
>>> --no-tiled-backing-store or not.
>>> AC checks make sense to me (unless we decide not to support non Ac
>>> composition mode on UI process side.). Coordinated graphics checks seem
>>> un-necessary as most of the classes are WebKit2 related. Someone more
>>> familiar with the code might think otherwise :)
>>>
>>> Reg Reviewers:
>>> You already have Laszlo,* Gyuyoung Kim participating in the discussion.
>>> Kenneth, MIkhail are already in cc.
>>>
>>> *
>>> *As you have already split the patches to smaller ones, you might want
>>> to create new bugs to each one and make the current one as blocked by
>>> others. This would at least help to focus the discussion for that
>>> particular check. (i.e coordinated graphics, tiledbackinstore and AC )
>>>
>>> *
>>> *br,
>>> Kalyan
>>> *
>>>
>>> On Thu, Mar 28, 2013 at 10:13 PM, Ed Bartosh <bartosh at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Thanks for you comments guys. I really appreciate that.
>>>>
>>>> I'd like to point out that even if xserver doesn't have regression my
>>>> fixes still make sense as they wrap code in #ifs depending on the features
>>>> like 3D_GRAPHICS, ACCELERATED_COMPOSITING, etc. So, they have some value by
>>>> themselves, not just because they fix --no-tiled-backing-store build.
>>>>
>>>> Considering Gyuyoung's comment in the bug about removing coorditaned
>>>> graphics I'm going to split my patch to several patches just to make
>>>> them accepted easier.
>>>>
>>>> Sorry for the newby question. Any suggestions whom to ask for review?
>>>> I'm new to this project and it's not clear for me what to do to make my
>>>> changes landed in the tree faster.
>>>>
>>>> Thank you,
>>>> Ed
>>>>
>>>> 2013/3/28 Tiago Vignatti <tiago.vignatti at linux.intel.com>
>>>>
>>>>> Xorg 1.13.2 has the proper fix in place. In the ideal world, distros
>>>>> would update for the latest minor version of Xorg and then you would just
>>>>> fetch it in your machine...
>>>>>
>>>>> Tiago
>>>>>
>>>>>
>>>>> On 03/28/2013 03:36 AM, Gyuyoung Kim wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> As I commented on the bug, I think it would be best X server 1.13.0
>>>>>> supports WebKit EFL layout test. However, if it will not support EFL
>>>>>> layout test in the near future, it looks we may need to support
>>>>>> --no-tiled-backing-store option again. Because I also heard that some
>>>>>> WebKit EFL engineers suffered from this issue. But, I still think best
>>>>>> is to support X server 1.13.0 on EFL.
>>>>>>
>>>>>> Any other opinions?
>>>>>>
>>>>>> Gyuyoung.
>>>>>>
>>>>>> On Thu, Mar 28, 2013 at 9:06 AM, Ed Bartosh <bartosh at gmail.com
>>>>>> <mailto:bartosh at gmail.com>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I need your suggestions.
>>>>>>
>>>>>> I'm trying to fix EFL build with disabled accelerated composition
>>>>>> (--no-tiled-backing-store build option).
>>>>>> I used this option because of X server 1.13.0
>>>>>> <http://lists.webkit.org/**pipermail/webkit-efl/2012-**
>>>>>> November/000434.html<http://lists.webkit.org/pipermail/webkit-efl/2012-November/000434.html>>
>>>>>> issue,
>>>>>>
>>>>>> mentioned here:
>>>>>> http://trac.webkit.org/wiki/**WebKitEFLLayoutTest#**Knownissues<http://trac.webkit.org/wiki/WebKitEFLLayoutTest#Knownissues>
>>>>>> I'm trying to build on Ubuntu 12.10, which has X server 1.13.0
>>>>>> with
>>>>>> this regression.
>>>>>>
>>>>>> It was not that easy to fix this as I suspected as it's required a
>>>>>> lot of changes, but it was fun and I learned a bit of WebKit code.
>>>>>> You can see some details in this bug:
>>>>>> https://bugs.webkit.org/show_**bug.cgi?id=11315<https://bugs.webkit.org/show_bug.cgi?id=11315>
>>>>>> <https://bugs.webkit.org/show_**bug.cgi?id=113153<https://bugs.webkit.org/show_bug.cgi?id=113153>
>>>>>> >3
>>>>>>
>>>>>>
>>>>>> Can you please suggest what should I do next? Should I split this
>>>>>> patch to several patches or leave it as it is? Whom to ask for
>>>>>> review?
>>>>>>
>>>>>> Considering the amount of changes was it at all feasible to fix
>>>>>> this
>>>>>> build or it would be better to simply get rid of
>>>>>> --no-tiled-backing-store option?
>>>>>>
>>>>>> Thank you,
>>>>>> --
>>>>>> BR,
>>>>>> Ed
>>>>>>
>>>>>> ______________________________**_________________
>>>>>> webkit-efl mailing list
>>>>>> webkit-efl at lists.webkit.org <mailto:webkit-efl at lists.**webkit.org<webkit-efl at lists.webkit.org>
>>>>>> >
>>>>>> https://lists.webkit.org/**mailman/listinfo/webkit-efl<https://lists.webkit.org/mailman/listinfo/webkit-efl>
>>>>>>
>>>>>>
>>>>>> --
>>>> BR,
>>>> Ed
>>>> _______________________________________________
>>>> webkit-efl mailing list
>>>> webkit-efl at lists.webkit.org
>>>> https://lists.webkit.org/mailman/listinfo/webkit-efl
>>>>
>>>>
>>>
>>
>>
>> --
>> BR,
>> Ed
>>
>
>
--
BR,
Ed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-efl/attachments/20130329/7b19373b/attachment-0001.html>
More information about the webkit-efl
mailing list