opengl - Is double buffering needed any more -
as today's cards seem keep list of render commands , flush on call glflush
or glfinish
, double buffering needed more? opengl game developing on linux (ati mobility radeon card) sdl/opengl flickers less when sdl_gl_swapbuffers()
replaced glfinish()
, sdl_gl_setattribute(sdl_gl_doublebuffer,0)
in init code. particular case of card or such things on cards?
edit: i've discovered cause kwin. appears datenwolf said, compositing without sync cause. when switched off kwin compositing, game works fine without source code patches
double buffering , glfinish
2 different things.
glfinish
blocks program, until drawing operations completed.
double buffering used hide rendering process user. without double buffering, each , every single drawing operation become visible immediately, assuming display refresh frequency infinitely high. in practice display artifacts, parts of scene visible in 1 state, rest not visible or in other state, picture incomplete, etc. double buffering avoids first rendering buffer, , after rendering has been finished swapping front buffer, gets sent display device.
now today compositing window management becomes prevalent: windows has aero, macos x quartz extreme , on linux @ least unity , gnome3 shell use compositing if available. point is: compositing technically creates doublebuffering: windows draw offscreen buffers , of these final screen composited. if you're running on machine compositing, double buffering kind of redundant if performed in program, , it'd take kind of synchronization mechanism, tell compositor when next frame ready. macos x has this. x11 still lacks proper synchronization scheme, see post on maillist: http://lists.freedesktop.org/archives/xorg/2004-may/000607.html
tl;dr: double buffering , glfinish
different things, , need double buffering (of sort) make things good.
Comments
Post a Comment