wxruby users - Mar 2008 - Re: Tearing in my buffered animation test script...

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 Fenton and Mario Steele 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

Jay McGavren wrote:
> Paul w Florczykowski wrote:
>   
>> 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.
Yep, it''s in the 1.9.5 release. I''d be interested in any
feedback you
have on how it works with Zyps

best
alex

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.
-- 
Posted via http://www.ruby-forum.com/.