On Wed, Jan 13, 2010 at 3:55 AM, Chia-I Wu <olva...@gmail.com> wrote:
> On Wed, Jan 13, 2010 at 2:52 AM, Luca Barbieri <l...@luca-barbieri.com> wrote:
>> Doesn't this make two DRI2GetBuffers protocol calls, in case of a resize?
> I expect resizing happens rarely.

It likely happens every frame while the user is resizing the window,
and it's relatively expensive (at least 7 system calls + scheduling +
work in the X server and the DRM memory manager).
Also, having to do this redundant work is a sign that the design can
be improved.

It's your call, but I think your:
>  if (not forced) {
>    get_current_sequence_number();
>    if (seq_num has not changed)
>      continue;
>  }
>  validate_and_update_buffers();

reformulated as

validate_and_get_current_sequence_number();
if (not forced and seq_num has not changed)
   continue;
update_buffers();

is the best idea, with DRI2GetBuffers done in
validate_and_get_current_sequence_number(), and the results reused in
update_buffers().

Or if you prefer a single function, then my approach puts that logic
in the validate function by taking the sequence number as in/out.

> Plus, I want to hook winsys->update_buffer.  It is called when the user calls
> glViewport.  It will set "force_validate" and avoid the first call.

Shouldn't the glViewport hook simply cause a call to validate which
otherwise would not have happened? (in the single-buffering case)
Wouldn't ignoring the sequence number (which is what forced validation
does) make sense only if the surface or desired attachments change?

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to