nanogui: nanox double buffering


Previous by date: 13 Jun 2007 18:11:20 +0100 Re: nano-X crashes on munmap, Frederic.LAMBERT.fr.thalesgroup.com
Next by date: 13 Jun 2007 18:11:20 +0100 Re: nanox double buffering, Greg Haerr
Previous in thread: 13 Jun 2007 18:11:20 +0100 Re: nanox double buffering, Greg Haerr
Next in thread: 13 Jun 2007 18:11:20 +0100 Re: nanox double buffering, Greg Haerr

Subject: Re: [nanogui] Re: nanox double buffering
From: Junior ####@####.####
Date: 13 Jun 2007 18:11:20 +0100
Message-Id: <BB1BBC8BA6C.0000034Cejr@inbox.com>

>> I do GrFillRect()
>       GrText()
>       GrCopyArea()
> in that order and I see undesired horiz lines.
> 
> If we're going to get down-and-dirty, then replace
> the GrFillRect call above with a for() loop
> drawing horizontal lines, or pixels even.  Then,
> see if the flicker is still there.  If it is, then I would
> say it might be a hardware issue related to just drawing
> that color in the screen location, rather than anything
> to do with filling the rectangular area.
> 
> I'm assuming that the screen isn't in fact repainted
> the same way when GrFillRect isn't used, so we're
> not yet really debugging GrFillRect vs another method
> of filling that rectangular space.

I haven't tried your suggestion yet but I stumble on something as I went 
through some ideas I have.
I'm dying to explain this one.
Below is part of my event loop, the part that actually updates the screen:


int i = 0;
void handle_event(void)
{
    if((OT_SFLAG & OT_SCRN_REWR) !=0)
    {
            GrFlush();
            printf("Flip\n");
if(i < 1){
    i++;
            printf("cols: %d, rows: %d, active:%d\n",tscrn_info.cols,tscrn_info.rows,dbuff->active);
            printf("viscols: %d, visrows: %d\n",tscrn_info.viscols,tscrn_info.visrows);
            GrFlipBuffers(dbuff);
            GrSetGCGraphicsExposure(scrn_gc, GR_FALSE);
            printf("Copy\n");
            GrCopyArea(dbuff->buf[!dbuff->active], scrn_gc, 0, 0, tscrn_info.viscols,
                        tscrn_info.visrows, dbuff->buf[dbuff->active] ,0, 0,MWROP_COPY);
            GrSetGCGraphicsExposure(scrn_gc, GR_TRUE);
            main_window = dbuff->buf[!dbuff->active];
         }

...
}

With this configuration, the screen is perfectly still, updating as expected.
Without the "if" statement there is undesirable flashes on the screen that seem to
occur during the GrCopyArea. Atleast I didn't seen the horiz lines during the copy.
Nonetheless, if I'm writing to the main_window which is not active, 
Why is the screen being updated? That's whay I'm dying to explain.

Any senario is welcome.

____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth

Previous by date: 13 Jun 2007 18:11:20 +0100 Re: nano-X crashes on munmap, Frederic.LAMBERT.fr.thalesgroup.com
Next by date: 13 Jun 2007 18:11:20 +0100 Re: nanox double buffering, Greg Haerr
Previous in thread: 13 Jun 2007 18:11:20 +0100 Re: nanox double buffering, Greg Haerr
Next in thread: 13 Jun 2007 18:11:20 +0100 Re: nanox double buffering, Greg Haerr


Powered by ezmlm-browse 0.20.