From: Pierre Willenbrock <pierre@pi...> - 2009-04-27 23:13:38
Ian Romanick schrieb:
> Pierre Willenbrock wrote:
>> Ian Romanick schrieb:
>>> Pierre Willenbrock wrote:
>>>> Additionally, in mesa, src/mesa/drivers/dri/intel/intel_tex_image.c,
>>>> intelSetTexBuffer2, color_rb(the front buffer) is accessed without
>>>> is_front_buffer_rendering being set to true, so RGBA visuals don't work
>>>> when doing opengl compositing.
>>> This is what mesa-tex_image-front-buffer.patch is about? I'm not sure I
>>> completely follow. Could you elaborate?
>> Not all of mesa-tex_image-front-buffer.patch. I don't know if the
>> initialisation of is_front_buffer_rendering is needed, it seems to work
>> In intelSetTexBuffer2 there is this sequence:
>>> intel_update_renderbuffers(pDRICtx, dPriv);
>>> rb = intel_fb->color_rb;
>>> /* If the region isn't set, then intel_update_renderbuffers was unable
>>> * to get the buffers for the drawable.
>>> if (rb->region == NULL)
>> So, it expects intel_update_renderbuffers to fill the
>> intel_fb->color_rb->region of the dPriv. This only happens, if
>> is_front_buffer_rendering is true(or if there is no back buffer). Maybe
>> something more complex is needed, forcing is_front_buffer_rendering to
>> true was the easiest way to get the region allocated.
> Okay, I see what's going on. This is the pixmap case. We handle this
> case differently on the server, so I think we just need to handle it
> even more differently.
> Right now the client only asks for the front-buffer when it's going to
> do front-buffer rendering. However, the server always creates the real
> front-buffer so that CopyRegion and friends will work. It only does
> this when the drawable is a window. I was under the impression that
> only windows had back-buffers. Is this a pixmap with a back-buffer? If
> so, try the attached xserver patch. I haven't tested it, but I think it
> should fix this problem.
The patch works.
I _think_ those are windows, not pixmaps. Windows with RGB visual did
work, only windows with RGBA visuals did not show up. But i don't know
exactly which visual is chosen(xwininfo only shows the visual class and
depth), so maybe the RGB ones did not have a back buffer, but the RGBA
Those windows are rendered through composite extension and
texture-from-pixmap, so they may well be pixmaps posing as windows, or
something. I have no idea how that works.