On Tuesday 25 September 2007 04:31:04 am Alexandre Julliard wrote:
> Chris Robinson <[EMAIL PROTECTED]> writes:
> > +    if(w > 0 && h > 0) {
> > +        XFlush(gdi_display);
> > +        XCopyArea(gdi_display, physDev->gl_drawable, physDev->drawable,
> > +                  physDev->gc, 0, 0, w, h, physDev->dc_rect.left,
> > +                  physDev->dc_rect.top);
>
> Why do you need an XFlush here?

Given the nature of glFlush/glFinish, I think it would probably be correct 
behavior to make sure the X copy command is flushed by the time the GL 
functions finish, too. Why it ended up before the copy though, I don't know.

> > +    if(data->whole_window && vis->visualid ==
> > XVisualIDFromVisual(visual)) +    {
> > +        TRACE("Whole window available and visual match, rendering
> > onscreen\n"); +        goto done;
> > +    }
> > +
> > +    if(!composite_gl)
> > +        goto done;
>
> There's no sense in having a config option for this since the
> alternative doesn't work anyway, particularly since you removed the
> scissor support.

True. I guess I can use an option just for extra onscreen pixel formats being 
composited instead, in a seperate patch of course.

> > +        data->gl_drawable = XCreateWindow(gdi_display, root_window, -w,
> > 0, w, h, +                                          0, vis->depth,
> > InputOutput, +                                          vis->visual,
> > +                                          CWColormap |
> > CWOverrideRedirect, +                                          &attrib);
>
> The window needs to be created on the thread display, and as a child
> of the main window.

With the child being parented to the main window, a BadWindow error sometimes 
crops up on XDestroyWindow for the X11 child. I couldn't see why, but 
parenting it to the root_window works. Would that be due to using gdi_display 
for creating/destroying the child?

> > +static void update_gl_drawable(struct x11drv_win_data *data)
> > +{
> > +    unsigned int border, depth;
> > +    int x, y, w, h;
> > +    Window root_win;
> > +
> > +    if(!data->gl_drawable)
> > +        return;
> > +
> > +    wine_tsx11_lock();
> > +    XGetGeometry(gdi_display, data->gl_drawable, &root_win, &x, &y,
> > +                 (unsigned int*)&w, (unsigned int*)&h, &border, &depth);
>
> You must not use XGetGeometry, this incurs a server round-trip.

Is it safe to call XMoveResizeWindow even if the size didn't change, and have 
X make it a no-op (or at least be negligible for processing time)? Calling to 
resize the child window every time the hwnd simply moves (or whenever it 
thinks it resized/moved) can cause it to be done unnecessarilly often.


Reply via email to