Michel Dänzer wrote: > On Fri, 2010-01-22 at 08:40 -0800, Keith Whitwell wrote: >> It's a very rare application that can render half a frame to one sized >> framebuffer and the other half to another and expect to have a >> meaningful result. >> >> It's also incredibly difficult to write a driver that produces any >> sensible result when the render-target size changes halfway through a >> frame. There are a bunch of reasons for this, including the fact that >> the driver will have unflushed command buffers referring to the old >> size that are suddenly invalid when a new size materializes. > > Right, that's why I was worrying about processing the DRI2 buffer > invalidate event in the middle of rendering a frame. But Francisco > clarified that it's only processed when the application is actively > processing X11 events, which should usually only be the case between > rendering frames. > > >> My pet take on this is that we should go one step further and modify >> GLX semantics to allow a stretch blit on swapbuffers to scale the >> rendered image up/down to the new window size. > > I think it's better to follow the X11 window gravity than to scale. DRI2 > may accidentally already be doing this for the majority of apps which > use the default gravity. :)
Agreed. It should behave the same as if you had any busy X client that didn't repaint its window after a resize. A stretch blit would be just as jarring to the eye as an unpainted window (though in a different way). Jordan -- Jordan Crouse Qualcomm Innovation Center Qualcomm Innovation Center is a member of Code Aurora Forum ------------------------------------------------------------------------------ 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
