On Thu, Feb 18, 2010 at 09:19:46PM +0200, Pauli Nieminen wrote:
> On Thu, Feb 18, 2010 at 8:31 PM, Francisco Jerez <curroje...@riseup.net> 
> wrote:
> > With current HEAD, if an app mixes GL and X11 calls, resizing could lead
> > to broken and incompletely rendered frames, as in the old DRI1 days. The
> > succession of events would be something like:
> >
> > * The app renders half a frame.
> > * It does something that makes libX11 process its input buffer (Any
> >  round-trip would do it, not only the X rendering commands). The DRI2
> >  event arrives at this point.
> > * The app tries to render the other half, dri_update_buffer realizes the
> >  window has been resized so it swaps buffers, throwing away the first
> >  half.
> >
> > However, I admit I don't have any real-life apps that could lead to
> > this, so this could very well be called a purely theoretical concern and
> > a case of pointless overengineering.
> >
> 
> If you want to overengineer you could make blit to screen handle
> scaling of frame in case window sizes doesn't match the size that
> frame was rendered at. Private rendering buffer rescaling would happen
> in dri code after buffer swap only. This would quarantine that
> rendering buffer wouldn't require scaling in middle of frame.

Application generally don't want to rescale the window content when
the size changes. They just want to move stuff around and resize some
elements of the UI. So I'm guessing this kind of whole window scaling
would look quite ugly. Shouldn't it just respect the window's bit
gravity instead?

-- 
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to