<div dir="ltr">De-<span style="font-size:12.8px">duplicating</span> and then trimming down works for me.<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 19, 2017 at 3:31 AM, Emil Velikov <span dir="ltr"><<a href="mailto:emil.l.velikov@gmail.com" target="_blank">emil.l.velikov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 18 October 2017 at 23:36, Gurchetan Singh<br>
<span class=""><<a href="mailto:gurchetansingh@chromium.org">gurchetansingh@chromium.org</a>> wrote:<br>
>> Then again, I'd suggest keeping that as separate series. These patches<br>
>> started as a way to minimise the duplication we have in drivers/dri2.<br>
><br>
> I'm fine with dri2_$action_$object. We can modify the existing functions<br>
> later, but I recommend adopting more concise conventions in this patchset,<br>
> i.e:<br>
><br>
> dri2_egl_surface_record_<wbr>buffers_and_update_back_buffer --><br>
> dri2_set_back_buffer_surface<br>
> dri2_egl_surface_free_<wbr>outdated_buffers_and_update_<wbr>size --><br>
> dri2_fixup_surface<br>
> dri2_egl_surface_update_<wbr>buffer_age --> dri2_update_age_surface<br>
> dri2_egl_surface_get_image_<wbr>front --> dri2_get_front_image_surface<br>
><br>
</span>Sure thing, let's use consistent names with this series.<br>
<span class=""><br>
>> goal the series is to a) remove a handful of the ifdef spaghetti and<br>
><br>
> I agree, struct dri2_egl_surface can be refactored. I would advocate a<br>
> solution where the surface (a) has everything a platform needs but nothing<br>
> else (b) has a minimal amount of duplication. I would like to look at the<br>
> struct and see if it defines buffers[5], it must mean the platform<br>
> implements get_buffers_with_format for example. If a platform doesn't<br>
> define color_buffers, it means EXT_buffer_age is not used for whatever<br>
> reason. Everything has dri_image_front -- then everything must use the<br>
> image extension. I think this type of self-consistency is useful, from a<br>
> code is documentation point of view. Here's pseudo-code of what I would<br>
> want:<br>
><br>
</span>I agreed with the goals but I would swap the order/priority -<br>
de-duplicate, then trim down.<br>
By de-duplicating/refactoring one could add support for X/Y fairly<br>
easily. Once all that is done, we can polish ;-)<br>
<br>
I fear that otherwise there will be a lot of unnecessary churn.<br>
<br>
Thanks<br>
<span class="HOEnZb"><font color="#888888">Emil<br>
</font></span></blockquote></div><br></div></div>