Paul w Florczykowski wrote:
I have tested your application, and indeed there is great
deal of flicker as expected. You are not making any
particular errors in your code; the problem occurs because
the drawing, or more precisely, the copying of graphics
(blit) is not synchronized with the vertical sync signal
your screen receives from your graphics card. (I’m speaking
in terms of analog signal CRT, but actually this applies to
any kind of digital screen as well, as far the application
is concerned)
Actually, Alex F. and Mario S. helped me resolve most of my
flicker issues just by speeding up my drawing routine. On my Windows
box the flicker is no longer noticeable, even though I don’t do a
vsync.
I think I posted a flicker-free version of the test script to this
list (check the archives), but if not you can check the source for my
main app (http://jay.mcgavren.com/zyps) to see what we’re currently
doing.
What you are currently doing is similar but lacks the point
(2). wxRuby aims to support this on a lower level (i
think). There is a method called “paint_buffered” (in stead
of “paint”) that provides a BufferedDC-object instead of
ClientDC or DC.
…
Sadly enough, this feature does not seem to be working
properly with wxruby 1.9.5.
I heard from Alex at one point that paint_buffered was working in the
Subversion version, but I don’t know if that’s made it into a release
yet.
-Jay McGavren
http://jay.mcgavren.com/zyps
Thanks for your replies.
Well I assumed double buffering automatically implies vertical sync, but
ofcourse it actually means drawing on offscreen buffer first; with or
without vsync…- While I’m rather new to both Ruby and WxRuby (and for
that matter to any GUI toolkit at all:) I have done my share of
programming graphics using Direct3D and other APIs specifically designed
for that. In that world there is almost always some easy way to
synchronize the actual copy or buffer swap with the vertical blank
period of the screen.
For example the Present(…) method of the rendering device
interface in DirectX 9, automatically waits for the V-blank period
before it swaps buffers, provided it is called with correct arguments.
And since I come from there I was kind of expecting similar
solutions for any kind of graphics.
However after doing some research I realized that the opposite holds for
the world of GUI APIs. On Windows (XP at least, don’t know about Vista)
it seems very hard to get any info about the current position of the
electron ray from the OS, unless working with either DirectX, OpenGL or
directly with the graphics driver. And that is probably the right
approach unless one is generating a lot of fast changing screen content
at high framerates - because first then the shearing will be noticeable
unless vertiacally synced.
As for my own WxRuby-learning-application, I’m also completely satisfied
with copying to the frontbuffer without the vsync, feel free to take a
look: http://web.comhem.se/paul/triplot . The shearing is there, but I
have to look very hard to see it. When I saw info on the paint_buffered
method that stated it was there to faciliate flicker-free drawing I
assumed it was supposed to be vertically synced just because of a
preconception, sorry about that.
And… I took a look at the Zyps application (really cool). As you say,
there is no visible shearing.